On Tue, 28.06.16 05:49, Jörg Thalheim (joerg.syst...@higgsboson.tk) wrote:
> Hi, > > when using zfs in combination with systemd, users run into the following > problem: > > - zfs manages mountpoints on its own and systemd is not aware of those. what do you mean by that? systemd tracks /proc/self/mountinfo. Are you saying those "mounts" don't appear there? If so, that appears to be seriously borked in the zfs kernel code... > - this leads to problems, when mountpoints for other filesystems are mounted > on directories in a zfs dataset or files are created in a directory before > zfs could > mount its dataset there. Not sure I grok this. Or are you saying that zfs uses a different source of configuration than /etc/fstab for its mounts? If so, it should either write a generator for that and let systemd do the work, or make sure it establishes its mounts atomically. (by prepping them somewhere and then using MS_MOVE to move them into place, for example). This is however not going to work as soon as a non-zfs file system shall be moutnable into some dir provided by zfs. > It should be also noted that those filesystems will be not mounted using > mount(2), > but the command interface `zfs mount` except mountpoint is set the > `legacy` This sounds pretty broken. Why don't they provide a mount.zfs binary, similar to how all other file systems do it that need to do something special on mount? > However currently some zfs services exists which import zfs pools after the > generator run: > > ```/usr/lib/systemd/system/zfs-import-scan.service > [Unit] > Description=Import ZFS pools by device scanning > DefaultDependencies=no > Requires=systemd-udev-settle.service > After=systemd-udev-settle.service if zfs requires "udev-setlle", then that's broken and very very sad. No new technology should need that. > As generators will run before unit I run into a Chicken or the egg problem. > I would appreciate, if you have suggestions how to make this scheme > compatible > with the way systemd handle mounts. If zfs requires an explicit "scan" phase, that needs to be called after all storage has shown up then it is simply incompatible with how today's device management works. There's simply no point in time where all hardware has to have shown up. Such a concept is incompatible with today's hardware which can pop up any time, and can take all the time it wants to show up. zfs has to be able to deal with devices coming any time and it should not expect to be run when "all has shown" up. my recommendation would be to work with the zfs guys to adapt it to how modern storage works, stop using udev-settle and make sure they implement a generator, and a mount.zfs plugin for /bin/mount. Otherwise it's always going to be more or less incompatible with systemd and how things generally work on Linux these days. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
