[systemd-devel] Integrating better with systemd

[Manuel Amador]

On a more on-topic question:

I have two pools composed of several devices each.  One of those pools is 
available right after dm-crypt in the initrd, and contains the root file 
system plus a bunch of other file systems.  I am handling that using 
generators.  The other pool, well, gets no handling since it is discovered 
right around fedora-storage-init-late, so it does not get imported nor do its 
filesystems get mounted.

Is there a way I could inject mount units for those filesystems *during* boot?  
Sort of like "modifying fstab", and expecting systemd to pick those 
modifications up?

Can this be done?

How does udev play into this?  Can udev announce the availability of whole 
pools of devices?  How does btrfs assemble its array when one of the component 
devices is available and was announced by udev, but the other components are 
not available yet?

On Sunday, March 25, 2012 21:14:01 Manuel Amador wrote:
> For a while now, I've been experiencing a few woes related to systemd,
> booting with ZFS on the root, underlied by dm-crypt, and my generator-based
> approach.
> 
> Here is the ideal situation I would like to have:
> 
> During initramfs:
> 
> - decrypt all available initial volumes (done by Fedora)
> - import ZFS pools (done by our scripts)
> - mount root file system (done by our scripts)
> 
> During early boot:
> 
> - discover all file systems mountable and schedule them for mount (done in
> my branch)
> - perform late block storage initialization and decryption (done by Fedora)
> - import any newly available ZFS pools (not done)
> - schedule any new file systems available for mount (not done)
> 
> During  shut down:
> 
> - unmount everything (systemd does it)
> - export pools cleanly (not done)
>     because, if they are imported, the crypt FSes are never closed
> 
> The "not done" parts are really ticking me off.
> 
> It is supposedly possible that we can accomplish most of this stuff simply
> by using udev rules.  Udev rules could possibly announce "hey, I found a
> ZFS array component", and communicate to a userspace program that says "OK,
> this array is now ready to be assembled and imported, and it really belongs
> to this system, so import it now".  Or "hey I found a bunch of ZFS file
> systems after importing this array, and these file systems have a policy of
> mounting on import, so mount them in the right order now".
> 
> Of course, the question of "which file systems are essential for the system
> to boot up" is MUCH TRICKIER that way, because ZFS does not specify them on
> /etc/fstab.  So it might be worthwhile to keep my generator-based approach
> at least for early boot, and use the udev-based approach for pools that are
> made available later on during or after boot.
> 
> This would also give us hotplug and automount for free.
> 
> Can anyone give me more input and ideas?  I'd appreciate it a lot.  I'm
> crossposting to systemd-devel because I really have no idea, and this part
> is really not well documented.
> 
> Is anyone even using my branch of ZFS with systemd support?
-- 
    Manuel Amador (Rudd-O)
    http://rudd-o.com/