1,330
edits
Bootable Linux USB stick: Difference between revisions
→USB stick: hardware considerations
| Line 167: | Line 167: | ||
=== fill empty space of a partition with “zeroes” === | === fill empty space of a partition with “zeroes” === | ||
This could be done after deleting large amounts of data from the USB stick, and before saving and compressing an image of it, or before re-using the media with a fresh install. | This could be done after deleting large amounts of data from the USB stick, and before saving and compressing an image of it, or before re-using the media with a fresh install. | ||
USB sticks that support “Deterministic read data after TRIM” according to <code>hdparm</code>, and microSD cards (which | USB sticks that support “Deterministic read data after TRIM” according to <code>hdparm -I /dev/sdX</code>, and microSD cards (which have zeroes in free space after <code>fstrim</code> in a SD slot) should be TRIMmed because this does not wear out the storage cells. | ||
Other media: as root | Other media: as root | ||
| Line 195: | Line 195: | ||
=== TRIM === | === TRIM === | ||
==== USB sticks ==== | ==== USB sticks ==== | ||
TRIMming informs the 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" | TRIMming informs the 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". | ||
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 <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 our preferred 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''', 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''', 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>]. | ||
==== (micro)SD cards ==== | ==== (micro)SD cards ==== | ||
These support TRIM when in a SD slot, but not when inserted in a USB adapter. When in a SD slot, the <code>lsblk -D</code> command reveals that the card can be TRIMmed, and <code>fstrim</code> works. | These support TRIM when in a SD slot, but not when inserted in a USB adapter. When in a SD slot, the <code>lsblk -D</code> command reveals that the card can be TRIMmed, and <code>fstrim -v /dev/mmcXXXXX</code> works. | ||
== installation of crystallographic software == | == installation of crystallographic software == | ||