On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote: > On 7/1/21 7:55 PM, David Wright wrote: > > On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote: > > > > > I do not set the 'discard' (trim) option in fstab(5). If and when I > > > want to erase unused blocks (such as before taking an image), I use > > > fstrim(8). > > > > Can you elaborate on a couple of things: > > > > How do you "take an image". Is this equivalent to a conventional > > dd if=/dev/sda …, or to some other process? > > I wrote a script. To "take an image", the script invokes dd(1) and > pipes the output to gzip(1), copying raw device octets to a file. To > "restore an image", the process is reversed. > > > > When I copy an entire conventional drive or partition, all the > > free blocks/unused sectors are carefully transferred to the copy. > > Same here. > > > > What improvement does erasing unused blocks achieve? > > Zero blocks are readily compressed, reducing the size of the image file.
Ah, I see. So a spinning rust analogy might be: . Take an old conventional disk, sdz, where df shows 10% uasge, . cp /dev/zero a-file-on-sdz . rm a-file-on-sdz . dd if=/dev/sdz … and compressing it, saving ~90% space. But can I tweak my question a little— Say that /dev/sdz contained one partition, sdz1, which filled the disk and was a LUKS encrypted /home. In this case, the above would fail to save space because the raw device sdz would be full of "random" data. But what happens with an SSD? If, after the rm step above, you # fstrim /home the mountpoint, where /etc/fstab has the line /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home then what gets zeroed, the container or the contained? I can't put my finger on any documentation that spells it out. Cheers, David.
