Bootable Linux USB stick: Difference between revisions

Line 144: Line 144:
  rm /mountpoint_of_partition/delete.me
  rm /mountpoint_of_partition/delete.me


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 could be done after deleting large amounts of data from the USB stick, and before saving and compressing an image of it. USB sticks that support “Deterministic read data after TRIM” should instead be TRIMmed (see below) because this does not wear out the storage cells.


==== Initializing the stick ====
==== 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 <code>hdparm -I /dev/sdX</code> 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)
* set disk password, and erase it (which unsets the password):
* set disk password, and erase it (which unsets the password):
Line 156: Line 156:


==== TRIMming the stick ====
==== 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.
TRIMming informs the USB stick firmware about blocks of the filesystem that do not contain file 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]).
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>].
1,332

edits