1,330
edits
Bootable Linux USB stick: Difference between revisions
→for techies: taking care of the stick
| Line 135: | Line 135: | ||
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 seems to result in faster writes afterwards i.e. it may be a way to restore the write speed of the stick. | 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 seems to result in faster writes afterwards i.e. it may be a way to restore the write speed of the stick. | ||
A better method that does not wear the stick (flash media support a limited number of writes!) is to use TRIM. The SANdisk Extreme supports TRIM, as <code>hdparm -I</code> shows. However, neither the <code>fstrim</code> command nor the <code>discard</code> mount option work for USB sticks (at least not the ones that I tested), presumably because the USB bridge and controller do not pass the ATA trim command to the device. The workaround is to use the <code>wiper.sh</code> script which is part of the <code>hdparm</code> package. | A better method that does not wear the stick (flash media support a limited number of writes!) is to use TRIM. The SANdisk Extreme supports TRIM, as <code>hdparm -I</code> shows. However, neither the <code>fstrim</code> command nor the <code>discard</code> mount option work for USB sticks (at least not the ones that I tested), presumably because the USB bridge and controller do not pass the ATA trim command to the device. | ||
The workaround I found is to use the <code>wiper.sh</code> script which is part of the <code>hdparm</code> package. For me, this works beautifully, as verified with the [https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking test_trim.sh] script. Use it on your own risk! | |||