1,328
edits
Bootable Linux USB stick: Difference between revisions
→for techies: taking care of the stick
No edit summary |
|||
| Line 146: | Line 146: | ||
This is sensible to do after deleting large amounts of data from the USB stick, and before saving and compressing an image of it. It also usually results in faster writes afterwards i.e. it may be a way to restore the write speed of the stick (of course this depends on the specific hardware). | This is sensible to do after deleting large amounts of data from the USB stick, and before saving and compressing an image of it. It also usually results in faster writes afterwards i.e. it may be a way to restore the write speed of the stick (of course this depends on the specific hardware). | ||
==== Initializing the stick ==== | |||
<code>hdparm</code>'s (ENHANCED) SECURITY ERASE initializes the whole stick in a few seconds, and restores it to an almost factory-fresh condition, including zeroing the device. This works on all sticks where hdparm -I /dev/sdX reports "supported: enhanced erase" but if used wrongly (e.g. on the wrong device, or with the wrong options, or ...) it may brick your device, or delete valuable data! So use at your own risk: | <code>hdparm</code>'s (ENHANCED) SECURITY ERASE initializes the whole stick in a few seconds, and restores it to an almost factory-fresh condition, including zeroing the device. This works on all sticks where hdparm -I /dev/sdX reports "supported: enhanced erase" but if used wrongly (e.g. on the wrong device, or with the wrong options, or ...) it may brick your device, or delete valuable data! So use at your own risk: | ||
* check if <code>hdparm -I /dev/sdX</code> reports "supported: enhanced erase" and "not frozen" (to unfreeze a frozen diks, suspend your system with <code>pm-suspend</code> and wake it up again) | * check if <code>hdparm -I /dev/sdX</code> reports "supported: enhanced erase" and "not frozen" (to unfreeze a frozen diks, suspend your system with <code>pm-suspend</code> and wake it up again) | ||
| Line 151: | Line 152: | ||
hdparm --user-master u --security-set-pass Eins /dev/sdX | hdparm --user-master u --security-set-pass Eins /dev/sdX | ||
hdparm --user-master u --security-erase-enhanced Eins /dev/sdX | hdparm --user-master u --security-erase-enhanced Eins /dev/sdX | ||
If you tried with --security-erase-enhanced, but the disk does not support it, then an error will occur and the disk will still be locked after the failed command, and you will not be able to write anything to it! If this happens, you can unlock it with | If you tried with --security-erase-enhanced, but the disk does not support it, then an error will occur and the disk will still be locked after the failed command, and you will not be able to write anything to it! If this happens, you can unlock it with | ||
hdparm --user-master u --security-unlock Eins /dev/sdX</code> | |||
The <code>wiper.sh</code> script ( | ==== TRIMming the stick ==== | ||
Trimming means letting the USB stick firmware know about blocks of the filesystem that do not contain data. This is available for USB sticks for which <code>hdparm -I /dev/sdX</code> returns “Data Set Management TRIM supported”; if that command also returns “Deterministic read data after TRIM” then zeros are returned upon reads of TRIMmed blocks. | |||
The <code>wiper.sh</code> script (part of the <code>hdparm</code> source distribution) TRIMs ext3/ext4/xfs filesystems, but does not reproducibly seem to work for the SanDisk Extreme 32GB stick if the filesystem is mounted. This is probably due to the fact that this stick has a limitation of max 65536 blocks in one TRIM command (https://sourceforge.net/p/hdparm/bugs/63/). Since <code>wiper.sh</code> also works for unmounted filesystems, and the mapping of unused space is then obtained with a different tool, one should try with an unmounted filesystem as well - this worked for us in all cases tried so far (tested with [http://lightrush.ndoytchev.com/random-1/checkiftrimonext4isenabledandworking this script]). | |||
All other methods, like the <code>fstrim</code> command and the <code>discard</code> mount option '''do not work for USB sticks''', presumably because the usb-storage kernel module does not pass the ATA trim command through the USB bridge and controller to the device. The same goes for [http://unix.stackexchange.com/questions/97143/utility-to-trim-unallocated-space-on-drive <code>blkdiscard</code>]. | All other methods, like the <code>fstrim</code> command and the <code>discard</code> mount option '''do not work for USB sticks''', presumably because the usb-storage kernel module does not pass the ATA trim command through the USB bridge and controller to the device. The same goes for [http://unix.stackexchange.com/questions/97143/utility-to-trim-unallocated-space-on-drive <code>blkdiscard</code>]. | ||