On 2018-01-29 12:58, Andrei Borzenkov wrote:
29.01.2018 14:24, Adam Borowski пишет:
...
So any event (the user's request) has already happened. A rc system, of
which systemd is one, knows whether we reached the "want root filesystem" or
"want secondary filesystems" stage. Once you're there, you can issue the
mount() call and let the kernel do the work.
It is a btrfs choice to not expose compound device as separate one (like
every other device manager does)
Btrfs is not a device manager, it's a filesystem.
it is a btrfs drawback that doesn't provice anything else except for this
IOCTL with it's logic
How can it provide you with something it doesn't yet have? If you want the
information, call mount(). And as others in this thread have mentioned,
what, pray tell, would you want to know "would a mount succeed?" for if you
don't want to mount?
it is a btrfs drawback that there is nothing to push assembling into "OK,
going degraded" state
The way to do so is to timeout, then retry with -o degraded.
That's possible way to solve it. This likely requires support from
mount.btrfs (or btrfs.ko) to return proper indication that filesystem is
incomplete so caller can decide whether to retry or to try degraded mount.
We already do so in the accepted standard manner. If the mount fails
because of a missing device, you get a very specific message in the
kernel log about it, as is the case for most other common errors (for
uncommon ones you usually just get a generic open_ctree error). This is
really the only option too, as the mount() syscall (which the mount
command calls) returns only 0 on success or -1 and an appropriate errno
value on failure, and we can't exactly go about creating a half dozen
new error numbers just for this (well, technically we could, but I very
much doubt that they would be accepted upstream, which defeats the purpose).
Or may be mount.btrfs should implement this logic internally. This would
really be the most simple way to make it acceptable to the other side by
not needing to accept anything :)
And would also be another layering violation which would require a
proliferation of extra mount options to control the mount command itself
and adjust the timeout handling.
This has been done before with mount.nfs, but for slightly different
reasons (primarily to allow nested NFS mounts, since the local directory
that the filesystem is being mounted on not being present is treated
like a mount timeout), and it had near zero control. It works there
because they push the complicated policy decisions to userspace (namely,
there is no support for retrying with different options or trying a
different server).
With what you're proposing for BTRFS however, _everything_ is a
complicated decision, namely:
1. Do you retry at all? During boot, the answer should usually be yes,
but during normal system operation it should normally be no (because we
should be letting the user handle issues at that point).
2. How long should you wait before you retry? There is no right answer
here that will work in all cases (I've seen systems which take multiple
minutes for devices to become available on boot), especially considering
those of us who would rather have things fail early.
3. If the retry fails, do you retry again? How many times before it
just outright fails? This is going to be system specific policy. On
systems where devices may take a while to come online, the answer is
probably yes and some reasonably large number, while on systems where
devices are known to reliably be online immediately, it makes no sense
to retry more than once or twice.
4. If you are going to retry, should you try a degraded mount? Again,
this is going to be system specific policy (regular users would probably
want this to be a yes, while people who care about data integrity over
availability would likely want it to be a no).
5. Assuming you do retry with the degraded mount, how many times should
a normal mount fail before things go degraded? This ties in with 3 and
has the same arguments about variability I gave there.
6. How many times do you try a degraded mount before just giving up?
Again, similar variability to 3.
7. Should each attempt try first a regular mount and then a degraded
one, or do you try just normal a couple times and then switch to
degraded, or even start out trying normal and then start alternating?
Any of those patterns has valid arguments both for and against it, so
this again needs to be user configurable policy.
Altogether, that's a total of 7 policy decisions that should be user
configurable. Having a config file other than /etc/fstab for the mount
command should probably be avoided for sanity reasons (again, BTRFS is a
filesystem, not a volume manager), so they would all have to be handled
through mount options. The kernel will additionally have to understand
that those options need to be ignored (things do try to mount
filesystems without calling a mount helper, most notably the kernel when
it mounts the root filesystem on boot if you're not using an initramfs).
All in all, this type of thing gets out of hand _very_ fast.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
