5 ms·
sudo e4defrag / sudo dd if=/dev/zero of=/zeros; sudo rm -f /zeros While write intensive, I run this on my ZFS VMs on occasion to keep the zstd compression ra
by willis936 5y ago
sudo e4defrag /
sudo dd if=/dev/zero of=/zeros; sudo rm -f /zeros
While write intensive, I run this on my ZFS VMs on occasion to keep the zstd compression ratio high. No pretty interface, but it's still satisfying when I see the volume's compression ratio is close to entropy. Even in 2021. Even with all-flash.
- geoka9 5y agoNo need to sync before rm'ing?
- willis936 5y agoNot afaik. The dd operation returns when the virtual disk is full and linux won't run anything after the semicolon until the previous command returns. I'm not running any async disk behavior on the client.
- yoursunny 5y agoIn case the second sudo wants to ask for password but there's no disk space for logging, it's safer to: sudo bash -c 'dd if=/dev/zero of=/zeros; rm -f /zeros'
- willis936 5y agoI typically don't put sudos in my scripts but have found filling all free space is particularly hazardous. I ran into rm permissions issues once and had to sneak my way into a recovery environment to remove the file. I haven't ran into sudo timing out during the zeroing, but it is a hazard. This is a good tip.
- tambourine_man 5y agoAny effects on life time of the SSD?
- willis936 5y agoAll write operations reduce the life of the SSD. I use 50 GiB volumes on a 4x NVMe RAID-Z1. Each drive is rated for 3500 TBW. I also only call this script when I want to reclaim space, such as after downloading many large dependencies for a one-time build. My home use case is read-heavy, so I'm really not concerned. When one drive goes, I can replace it. If they all go at once: I have remote encrypted B2 backups.
- Isthatablackgsd 5y agoI thought defragging SSD/Flash-based devices is a big no no? Since that would reduce the lifecycle in a considerable way. Is that what TRIM is for?
- SavantIdiot 5y agoIts only a problem if the delta between adjacent bits grows too large. "Wear-leveling" is a type of auto-defrag that will shuffle data around intentionally to keep these deltas equivalent. "Program-erase" cycles (the lifetime of the gate oxide layer that you literally destroy) are an order of magnitude less worrisome, and the larger the drive the less this matters.
- 5e92cb50239222b 5y agoI always read (from sources like LKML, not random blog posts) that defrag on SSD is simply useless because you never know the actual physical placement of your blocks. You can write a sequential 512 MB chunk of data in a single file and have it exploded in 500k+ 4k blocks in different locations (or vice versa — a bunch of random writes to different sectors can be compacted into a single linear block). If you really need to defrag SSD (which somewhat helps IME if it was heavily used up to 100% capacity), copy everything to other storage, wipe it (preferably with NVMe/SATA commands, or at least do a full TRIM), and then copy everything back.
- hansel_der 5y agoif your first assertation is correct, and ssd's use internal mapping of physical and logical sectors, then your suggestion with wiping/rewriting would not work. i know that per SMART, disks (hdd and ssd) have to have extra space that will be used if an active sector goes bad, but idk about the total internal remapping on ssd's.
- nix23 5y agoI know that trick and it is NOT working with dev/zero on ZFS (compression), use dev/urandom instead.
- willis936 5y agoI know you're joking, but if any layreader comes across this: random data does not compress.