Dracut cpio-reflink feature detection

[mwilck]

Hi David,

here are 2 patches, the first fixes a minor issue in your code, the 2nd adds autodetection for cpio-reflink which we discussed in Jira.

Martin

[ddiss]

Thanks Martin! I'll collapse the dinfo fix in with my current upstream submission.
Regarding the is_reflink_supported() change - I'd prefer to only print a warning, rather than have it disable the explicitly enabled reflink option.

[mwilck]

I'd prefer to only print a warning, rather than have it disable the explicitly enabled reflink option.

Well, you did the same in your code (albeit only if dracut-cpio was unavailable). IMO the option must be disabled (with warning) if it can't possibly work. Otherwise people will complain to us (you :-) ) because they don't understand the feature (which isn't exactly trivial).

The relationship between the various options is a different issue. My idea was:

• disable cpio-reflink if conflicting options like --compress or --strip were used on the command line
• adapt compress and do_strip if they were just set in config files / from defaults and cpio-reflink is active.

I did not distinguish whether cpio-reflink itself was set on the command line or in config files/defaults. IMO command line should always take precedence, but it's unclear what to do if e.g. both --compress=xz and --cpio-reflink were given on the command line. Actually we should probably just error out in that case.

This is to to explain my line of thought. Feel free to modify this logic as you see fit. But if there are contradictory / inconsistent options, we must do something about it.

[ddiss]

I'd prefer to only print a warning, rather than have it disable the explicitly enabled reflink option.

Well, you did the same in your code (albeit only if dracut-cpio was unavailable). IMO the option must be disabled (with warning) if it can't possibly work. Otherwise people will complain to us (you :-) ) because they don't understand the feature (which isn't exactly trivial).

The relationship between the various options is a different issue. My idea was:

* disable `cpio-reflink` if conflicting options like `--compress` or `--strip` were used _on the command line_

* adapt `compress` and `do_strip` if they were just set in config files / from defaults and `cpio-reflink` is active.

I completely agree that these options should be consistent. --strip is already a warning. For compression, the lack of dracut-cpio stdout support is why I took the easy option of disabling it. I'll fix the inconsistency by adding support for compression.
dracut-cpio should work just fine, regardless of whether the underlying FS supports CoW reflinks. To make this clearer, maybe I should change the option to enhanced-cpio or something like that?

I did not distinguish whether cpio-reflink itself was set on the command line or in config files/defaults. IMO command line should always take precedence, but it's unclear what to do if e.g. both --compress=xz and --cpio-reflink were given on the command line. Actually we should probably just error out in that case.

dracut.sh processes cmdline arguments before handing config files, so I don't think precedence should be changed here. We could consider detecting conflicting config and cmdline parameters, but I'd prefer to keep it simple for now.

This is to to explain my line of thought. Feel free to modify this logic as you see fit. But if there are contradictory / inconsistent options, we must do something about it.

Thanks for the explanation :-)

[mwilck]

For compression, the lack of dracut-cpio stdout support is why I took the easy option of disabling it. I'll fix the inconsistency by adding support for compression.

Why the extra effort?

dracut-cpio should work just fine, regardless of whether the underlying FS supports CoW reflinks.

I have no doubt about that. But I was using a different definition of "work", see below.

To make this clearer, maybe I should change the option to enhanced-cpio or something like that?

My thinking (which obviously doesn't fully match yours) was that this option activates space-efficient initrd generation by making use of reflinks. Therefore I'd prefer a simpler option name such as --reflink. By the same mind set, I thought that this option should fail or print warnings if it can determine from the environment that space savings won't occur because reflinking won't work, or if conflicting options are detected.

Please take off your developer 🎩 for a while 😄. From a user perspective, it only matters whether reflinks are used, not which cpio executable creates them.

dracut.sh processes cmdline arguments before handing config files

Command line options set the -_l suffixed variables such as compress_l, which take precendence over all config file settings, independent of the order processed. E.g. SUSE currently sets compress="xz -0 --check=crc32 --memlimit-compress=50%" in 01-dist.conf, but I can override that by calling dracut --compress=cat.

[ddiss]

For compression, the lack of dracut-cpio stdout support is why I took the easy option of disabling it. I'll fix the inconsistency by adding support for compression.

Why the extra effort?

dracut-cpio should work just fine, regardless of whether the underlying FS supports CoW reflinks.

I have no doubt about that. But I was using a different definition of "work", see below.

To make this clearer, maybe I should change the option to enhanced-cpio or something like that?

My thinking (which obviously doesn't fully match yours) was that this option activates space-efficient initrd generation by making use of reflinks. Therefore I'd prefer a simpler option name such as --reflink. By the same mind set, I thought that this option should fail or print warnings if it can determine from the environment that space savings won't occur because reflinking won't work, or if conflicting options are detected.

dracut.sh already uses cp --reflink extensively when shuffling thing into the staging area, which is why I went with --cpio-reflink.

Please take off your developer tophat for a while smile. From a user perspective, it only matters whether reflinks are used, not which cpio executable creates them.

I'd be more inclined to say that the user doesn't care whether or not reflinks are used, they just want things to be as fast as possible. dracut-cpio should provide that in all cases, as data will either be reflinked or (when not available) be copied in kernel via splice().

I plan on updating the PR today with compression support and your fix squashed in.

[ddiss]

I missed a couple of other points...

For compression, the lack of dracut-cpio stdout support is why I took the easy option of disabling it. I'll fix the inconsistency by adding support for compression.

Why the extra effort?

It's not much in the way of effort, the dracut-cpio output just needs to get piped through $compress.

...

Command line options set the -_l suffixed variables such as compress_l, which take precendence over all config file settings, independent of the order processed. E.g. SUSE currently sets compress="xz -0 --check=crc32 --memlimit-compress=50%" in 01-dist.conf, but I can override that by calling dracut --compress=cat.

Thanks. I overlooked this, so will add _l precedence in the next round.

[ddiss]

I'm going to close this downstream PR. Please raise any further questions / concerns against the upstream PR at dracutdevs#1531 .

I think it probably does still make sense to retain the is_reflink_supported() logic for use when selecting defaults in suse.conf.example, but I think it can wait until the core functionality is upstream.