[zfs-discuss] UPDATE: Re: Integrating better with systemd
vahe at robotics.stanford.edu
Wed May 2 21:24:32 EDT 2012
I got the latest version I think (Rudd-O-zfs-zfs-0.6.0-rc8-168-g1373f52.zip).
After building, and installing, it still does not do anything for me. I am
using opensuse 12.1 with systemd. Are there additional steps to be taken
after installation? I could not find anything in the readme.
On Sunday, March 25, 2012 11:03:35 PM Manuel Amador wrote:
> In my tree, I have added Dracut code to export ZFS file systems, datasets
> and pools, such that when the computer is shut down, the pools do not
> remain in dirty state.
> This is needed in concomitance to a number of changes that have been
> happening, that make importing of the pool impossible if the pool wasn't
> cleanly exported on poweroff (which always happens when the root file
> system lives on the pool in question, unless my changes are applied).
> commit 9d75454ec2705662e94f98c539950ea2772c8bac
> Author: Manuel Amador (Rudd-O) <rudd-o at rudd-o.com>
> Date: Sun Mar 25 21:51:19 2012 -0700
> Added support for exporting pools during shutdown
> Tree: https://github.com/Rudd-O/zfs/
> On Sunday, March 25, 2012 21:14:01 you 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?
More information about the zfs-discuss