Bug 1164334

This is not an xfs[progs] bug; the device it is looking for is not available at the time XFS needs it.

I'm not sure where it should go ... let's try dracut for now.

(In reply to Eric Sandeen from comment #2)
> This is not an xfs[progs] bug; the device it is looking for is not available
> at the time XFS needs it.
> 
> I'm not sure where it should go ... let's try dracut for now.

That's not a dracut bug. This partition is used on the real root, not in the initramfs.

The problem is, that "logdev=.." has to be expressed in a device dependency. So the /mnt/test mount unit not only depends on "/dev/sdb", but also on "/dev/rhel/lv_journal01".

This can be solved from the systemd side by teaching fstab-generator about the logdev keyword.

So, systemd's "systemd-fstab-generator" is responsible for creating the mount units from /etc/fstab, with the right dependencies. 

I really don't want to have hacks for specific file systems in that tool, though, after all the various file systems have vastly different options and semantics for referencing external devices log file system logs. ext4 seems to prefer major/minor numbers while xfs resolves paths (including symlinks) inside the kernel. The options are named really differently. ext4 calls it journal_dev=, while xfs calls it logdev= and rtdev=. 

if the kernel folks can't agree in common naming and common semantics then systemd really isn't the place to abstract this brokeness away.

Hence: if you want automatic generation of the right depencies, then please do that in xfsutils: add a small generator there that parses /etc/fstab looking for xfs partitions, and adds .d/ drop-ins that add the dependencies on the right devices with that. Similar, if ext4 wants the same level of support they should add a generator that solves that specifically for ext4's options from a generator shipped with e2fsprogs.

For details on generators see:

http://www.freedesktop.org/wiki/Software/systemd/Generators/

Lennart, while some of the more oddball filesystem options might requires some custom work, I would expect and hope that systemd could handle common device dependencies like options containing /dev/mapper/$FOO

Systemd doesn't need to care whether it's referenced as journal_dev, logdev, or rtdev, or quxdev but surely it can recognize the part after the "=" - i.e. /dev/mapper/my-pretty-name 

Systemd must already be able to handle dependencies for the main device (right?), so why shouldn't it handle an option device as well?

IOWS if we have:

/dev/mapper/maindev	/mnt/test	xfs	defaults,logdev=/dev/mapper/logdev 1 2

How is it that /dev/mapper/logdev is xfs's responsibility, but /dev/mapper/maindev is handled just fine by systemd?

Lennart, what do you think?  re-implementing basic device dependency handling in several different filesystem utility packages just doesn't seem optimal.

If you'd be willing to give an example of what the output should look like, I'd take a stab at adding basic device option parsing to the existing fstab generator.  As it is, I don't know where to start.

systemd doesn't try to "guess" what mount options mean. We won't have heuristics in systemd that look at the mount options and adding deps to anything that "looks" like a device. I mean, first of all this wouldn't work, since some file systems reference those devices via major/minor anyway. And even if everybody would reference them via /dev/ full names, it doesn't necessarily mean that systemd really always should wait for it...

The generators allow you to extend the systemd dependency tree. Look at systemd-fstab-generator for an example how they work, and see the docs I linked for more information. Most likely you just have to iterate through fstab and create a single .requires/ symlink for the right device.

Alternatively, I am open to adding support for a generic scheme how these dependency device are handled. For example, if the ext4 and xfs people can think of a good generic scheme how we can recognize references to other devices in the mount options, then we can certainly support that in systemd. 

Another option would be to introduce x-systemd.requires= or so as additional userspace mount option in systemd-fstab-generator, and simply ask users to explicitly configure the dependencies with that when they specify logdev=. Or in other words, instead of just putting "logdev=/dev/foo" in the options, you'd always have to specify "logdev=/dev/foo,x-systemd.requires=/dev/foo". The first option would be passed to the kernel and tells XFS what to make of the device. The second option tells systemd-fstab-generator to add an additional dependency. This wouldn't be fully automatic then, but one could argue that it is more powerful. And given that logdev= is probably not the most commonly used option maybe dumping this problem on the admins is not the worst of ideas...

Summarizing, three options:

a) Unify in the kernel how additional devices are referenced by file system mount options. Then add support for recognizing this in systemd-fstab-generator.
b) Solve this in xfsprogs via a new generator, and do xfs-specific parsing of the mount options.
c) Make the dependency declarations explicit via a new "x-systemd.requires=" mount option, independent of logdev=, and make sure admins always add both mount options.

What I am really not interested in though is option:

d) Add all kinds of magic to systemd-fstab-generator to recognize all kinds of file system specific mount options, just because the kernel folks can't agree on a common interface for this.

Pick one of a), b) or c), I am fine with either.

Honestly, I think a) is already done, if you accept "option=<devicepath>" as the existing kernel standard.  These are the auxiliary device options I find in the kernel:

btrfs
  device=<devicepath>
xfs
  logdev=<devicepath>
  rtdev=<devicepath>
ext3
  journal_path=<devicepath>
ext4
  journal_path=<devicepath>
reiserfs
  jdev=<devicepath>

In every one of these cases, the specified device is required to mount.

(Yes, ext3/4 has a dumb device number option too, but it's deprecated and has the above modern alternative. I am happy to ignore it.  I can find no other similar non-device-path device-specification mount options)

Recognizing this in systemd itself has the benefit of being a centralized fix, and will make every system start working again with systemd, no other package updates or admin actions are required.  I don't think it's a lot of magic, it's only recognizing the single standard pattern above, "option=<devicepath>"

If filesystems have other weird & random fs-specific needs, I can see where a fs-specific generator makes sense.  But really, the above is just standard fare.

If you're concerned that it's assuming too much, what if each filesystem can simply provide a template of options which contain dependencies, i.e. if xfs had a template file containing:

rtdev=%d
logdev=%d

that could be parsed by the fstab generator, and know that "%d" is a device dependency if it matches the pattern above.  That way systemd is not assuming or maintaining anything fs-specific, the filesystems can give clear specifications, and filesystem utility packages don't need to carry around systemd bits.

-Eric

Lennart,

I just went to look at systemd-fstab-generator with an eye to modifying the script to parse the filesystem device parameters directly. Turns out that this is a binary and so i can't modify it with a text editor on my running system. I can't even understand what parsing is being done or the output format without having the systemd source code installed on my system. Ouch.

Look at it this way - I'm not anti-systemd at all. However,I'm not a systemd developer, nor have I any desire to do init system development. The proposed generator solution forces us to have to support systemd directly. That means we need conditional build infrastructure to support non-systemd package builders, not to mention the added complexity of supporting packages on systems where the init system is user selectable.\

I know, Lennart, that you don't care about non-systemd systems, but as the upstream pacakge maintainer I do - having to add package dependencies (both build- and installation- time) just to ensure a specific init system behaves correctly is fundamentally wrong. If the init system has internal dependcies it needs to generate to work correctly, then it's up to the init system developers to ensure those dependencies are corectly generated - it is not the responsibility of every 3rd party to ensure the init system works correctly.

The simple fact is that this is a problem introduced by systemd and is caused by a deficiency in it's fstab parser. The parser that can be easily extended to extract the small subset of device parameters and generate the dependencies systemd requires to boot. There's only a very small number of options you need to care about, as Eric documented above, and doing so keeps the init processing encapsulated within the init package.

IOWs, the most efficient, simple and effective solution for everyone is to add support to the systemd-fstab-generator to support these mount options, not demand everyone else write and maintain generators. Having everyone write their own generators is a sure road to inconsistency, bugs and madness...

-Dave.

(In reply to Eric Sandeen from comment #10)
> Honestly, I think a) is already done, if you accept "option=<devicepath>" as
> the existing kernel standard.  These are the auxiliary device options I find
> in the kernel:
> 
> btrfs
>   device=<devicepath>
> xfs
>   logdev=<devicepath>
>   rtdev=<devicepath>
> ext3
>   journal_path=<devicepath>
> ext4
>   journal_path=<devicepath>
> reiserfs
>   jdev=<devicepath>
> 
> In every one of these cases, the specified device is required to mount.

What kind of "standard" is this? The fact that you put together a table for this is indication enough that nothing is standard, certainly not the parameter name.

Is it that difficult to talk to your file system hacker friends and agree on a single name to name the option? A name that is unlikely to clash against similar parameters from any future file system? (i.e. don't pick "jdev" or so, since that is too likely to clash).

> Recognizing this in systemd itself has the benefit of being a centralized
> fix, and will make every system start working again with systemd, no other
> package updates or admin actions are required.  I don't think it's a lot of
> magic, it's only recognizing the single standard pattern above,
> "option=<devicepath>"

"single pattern"? It means adding either a table for the precise option name of the various file systems, or by adding heuristics, that guesses that something is a mount option of this type. Neither I want to see in my sources.

systemd is really not the place to add work-arounds for the fact that the kernel folks can't agree on a commons scheme to name their options.

> If filesystems have other weird & random fs-specific needs, I can see where
> a fs-specific generator makes sense.  But really, the above is just standard
> fare.
> 
> If you're concerned that it's assuming too much, what if each filesystem can
> simply provide a template of options which contain dependencies, i.e. if xfs
> had a template file containing:
> 
> rtdev=%d
> logdev=%d

I'd much rather prefer if the file systems would agree on a common name for the options, insteads of adding another indirection layer by defining a new attribute that exposes which option means what.

> that could be parsed by the fstab generator, and know that "%d" is a device
> dependency if it matches the pattern above.  That way systemd is not
> assuming or maintaining anything fs-specific, the filesystems can give clear
> specifications, and filesystem utility packages don't need to carry around
> systemd bits.

This sounds quite complex for a simple problem.

I mean, if you stick to a common name for the option, this not only makes the option easily udnerstandable to userspace, but also to admins.

(In reply to Dave Chinner from comment #11)
> Lennart,
> 
> I just went to look at systemd-fstab-generator with an eye to modifying the
> script to parse the filesystem device parameters directly. Turns out that
> this is a binary and so i can't modify it with a text editor on my running
> system. I can't even understand what parsing is being done or the output
> format without having the systemd source code installed on my system. Ouch.

you are funny. The file system code in the kernel isn#t shell either, how can you hack on that? 

The parsing is glibc setmntent(), it's very easy, very standardsy. 

But here you go, the sources are online:

http://cgit.freedesktop.org/systemd/systemd/tree/src/fstab-generator/fstab-generator.c

> Look at it this way - I'm not anti-systemd at all. However,I'm not a systemd
> developer, nor have I any desire to do init system development. The proposed
> generator solution forces us to have to support systemd directly. That means
> we need conditional build infrastructure to support non-systemd package
> builders, not to mention the added complexity of supporting packages on
> systems where the init system is user selectable.\

Hmm? Shipping a generator is just dropping in a file. That certainly doesn't break anybody's system even if he doesn't use system. You can also just add it to your RPM instead of upstream.

Anyway, if you want the options supported by systemd, there are three ways I can live with, see comment #9. Pick one.

Then we pick c)

Update summary; not unique to xfs.

Having the data device on a normal partition and any dependent device on lvm fails for both ext4 and xfs, and presumably any other fs.

Also, if the data device and log device are both on lvm, it seems to work in F20 at least.  So that may be a workaround: keep both pieces on LVM.

FWIW, the reason I push back on "common" naming for the journal device is that it is not sufficient to solve the problem of external device dependencies in general; other dependent devices may exist now or in the future - see for example rtdev in xfs.

There may well be more dependent device specifications for other filesystems, in or out of the tree, now or in the future.  (specification of a dedicated metadata device, or a snapshot device, or whatever may come).  Rearranging just the journal device mount option name is not a permanent solution to the problem of systemd recognizing device dependencies at mount time.

c) is implented now upstream

*** Bug 1226375 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2092.html