Showing posts with label drive. Show all posts
Showing posts with label drive. Show all posts

2014-07-01

Hints: how to upgrade customized Micron C400 SSDs to the latest generic firmware version

Important notes:
  1. DISCLAIMER: this guide is provided here only "just for fun" for experimental, research and educational purposes without any guarantees (or warranties, responsibilities, obligations, liabilities etc.; even no repeatability guaranteed, as this guide has been based solely on just one particular specimen device, sorry), so use it at your own risk (even more, the so-called "reverse engineering" can possibly be illegal in some areas);
  2. ATTENTION (DANGER): it can result in an irreversible destruction of ALL or ANY data stored on the target device (including the loss of important metadata like device usage statistics, but it's not wise to hope it will heal / recover / restore any worn-out memory blocks / chips or make the device good as new in performance) and, in theory, on some other storage devices -- please back up ALL the valuable data FIRST;
  3. CAUTION: it may even brick your device;
  4. WARNING: moreover, it may void the warranty, if any.
  5. Feel safe & free to enjoy! ;-)

2014-06-10

HOWTO: work around SATA HDD hotplug problem (in Linux)

Sometimes some SATA controllers do not recognize an attached HDD if it was hot-plugged after the Linux system has been booted. Fortunately, there're some simple workarounds (note: it should work for some PATA controllers too).
  1. A standard "soft" solution (should work by default):
    1. Connect the HDD to the SATA controller (and make sure it doesn't get auto-recognized by the system).
    2. Force a rescan of SCSI buses:
      # for h in /sys/class/scsi_host/host*/scan; do echo "- - -" > $h; done
    3. Ensure the drive has been recognized (check the dmesg logs, run lsblk etc.) and enjoy it!
  2. A more "aggressive" method
    (note: some old SATA controller made by VIA Technologies and managed by sata_via kernel driver is used here for sample purposes; should work with any recent 2.6+ Linux kernel versions):
    1. To prevent any data loss, flush caches & unmount all the mounted partitions for all the drives connected to any VIA SATA controller(s) installed on the affected system!
    2. Remove the kernel driver module (verbosity is helpful sometimes):
      # modprobe -v -r sata_via
    3. Physically attach (or detach) any drives to the VIA SATA controller.
    4. Re-insert the kernel module:
      # modprobe -v sata_via
    5. Enjoy!
References:
  1. Scanning Storage Interconnects - RHEL7 Storage Administration Guide
---
Last updated: 2014-06-20

2013-01-06

HOWTO: stress-test a USB flash drive for bad blocks in Linux

Once upon a time you may like to test your USB flash drive [or maybe a SATA HDD, who knows] for bad blocks.

First of all, backup all the data stored on the target drive;
then you should unmount any mounted partitions located on that drive:
# umount /dev/sdz1
Then you can begin the tests (CAUTION: these tests will destroy all the stored data on the tested drive).

You can use dd utility to fill the drive with zeros:
# dd if=/dev/zero of=/dev/sdz
or with pseudorandom data:
# dd if=/dev/urandom of=/dev/sdz
and it will stop unexpectedly on a bad block.

And there's also a little more handy utility called badblocks:
# badblocks -wso /tmp/badblocks.log /dev/sdz
It will sequentially fill the entire /dev/sdz device with some patterns (0xAA, 0x55, 0xFF, 0x00), then read and compare the read data with an actual pattern. A list of bad blocks will be written to /tmp/badblocks.log file.

References: