On Do, 21.05.20 10:06, Tobias Hunger (tobias.hunger@xxxxxxxxx) wrote: > CopyFiles and CopyBlocks do make sense since they are probably going to get > used widely. I am not so shure about subvolunes and even less so about > setting up physical LVM volumes, multi-volume btrfs filesystems, > dm-integrety setups and a thousand other things! I would actually prefer to > see CopyFiles and CopyBlocks for the 90% that will not need more than that > and a more open approach as a fallback for the remaining 10%. Well, let's see when the need arises... > How about "SetupCommand=", that is run with the block device and maybe fs > type and options and must exit 0 when done successfully? We can think about that. But let's start out simple for now. I am not sure the LVM people are really — let's say — forward looking enough to see the benefit of the whole concept. In particular as such dynamic/elastic partition management is probably something they see as genuinely something LVM could do for people, except that it does not. > > > Well, my thinking was to mostly rely on the "gpt-auto" logic, > > > > i.e. that simply because they carry correct gpt type uuids systemd > > > > would discover and find them. > > > > > > gpt-auto is not enough. I will want to set up pretty complex things > > > like dm/crypto/etc. > > > > gpt-auto can cover LUKS/dm-crypt as well as dm-verity just fine. What > > else do you need? > > How about a partition for backups that is encrypted and uses > filesystem-based compression? How about a RAID array? There are thousands > of cool things you can do with new filesystems and device mapper! I think the truly useful stuff is something we should cover natively, and the rest is something people have to glue together on their own I guess.. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel