Here's the 31st post highlighting key new features of the current v257 release of systemd. #systemd257
In an earlier installment of this series we already talked about "systemd-repart", systemd's "elastic", automatic repartitioning tool, that can also be used as installer and image building tool.
One thing systemd-repart can do for you is to initialize the partitions it creates with initial data. This can be a freshly generated fs that it copies files into, but there's also CopyBlocks=…
… which operates on the block layer, and can initialize the partition from either a regular file (which then would typically contain a pre-made fs image), or another block device (in order to maybe replicate an existing partition onto a new disk, in a byte exact fashion).
With v257 CopyBlocks= gained one new feature: in addition to regular files and block devices you can now specify character devices as source to copy from too.
You wonder what that might be good for?
Well, one device in particular: /dev/urandom. Or in other words: you can now do CopyBlocks=/dev/urandom to initialize a partition with entirely random data, which is sometimes useful to systematically overwrite any previous contents it might have had.
Note that whenever systemd-repart initializes a partition it will anyway use the DISCARD hardware operation first to empty it, and it also ensures that any remaining super blocks from an older fs are erased no matter what.
However, both of these operations won't comprehensively overwrite the partitions, simply because that'd be just too slow potentially given today's disk sizes. But now you have a way to explicitly request this anyway.
You might wonder why supporting character devices as copy source even needs explicit support, given that supposedly on UNIX "everything is a file". Well, that's because that mantra is of course nonsense. There are major differences between block devices, regular files and…
…character devices. For example the size of a regular file you query with fstat(). The size of of a block device you query with the BLKGETSIZE64 ioctl() and a character device generally has infinite size. What's more important though is that block devices operate in multiples of some block size, and you better respect that when doing IO on them. Regular files and character devices however operate byte-exact. And there's more.
Anyway, that's it for today.
@pid_eins "Everything is sort of a file" doesn't have as nice of a ring to it, I guess 
@jawnsy I think "everything has an fd" would be a much better mantra, and one i could get behind, though unfortunately not really true, i.e. their are other handles around, such as inotify wds, keyring keys, sysv ipc keys and so on....
@pid_eins Maybe an operating system does too many things for generalizations like, "everything is a file," to be universally true?
If you say, "everything is a thing," then I guess it would be accurate and useless. And if you say, "everything is a file," or, "'i' before 'e', except after 'c'," then there are also various exceptions, lol
In any event, thanks for everything you do with systemd and also for these threads!
@pid_eins afaik securely overwriting an entire SSD manually, to prevent recovery of old disk contents, is not really possible though because SSDs have more storage space than they advertise and transparently remap logical blocks to physical blocks. you'd have to use the SSD's special "securely wipe the entire disk" command for that
@jann yeah i guess this feature is not so much about total destruction of the data, it's really just about making the stuff invisible.
I guess we could teach repart also to fire the right nvme commands to do a secure erase of the disk on request. Afaiu this couldnt be done for parts of the disk though, would always cover the full thing, hence probably would have to be exposed quite differently.