Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status

[Lennart Poettering <lennart@poettering.net>]

On Wed, 17.06.15 21:10, Goffredo Baroncelli (kreijack@libero.it) wrote:

> > Well, /bin/mount is not a daemon, and it should not be one.
> 
> My helper is not a deamon; you was correct the first time: it blocks
> until all needed/enough devices are appeared.
> Anyway this should not be different from mounting a nfs
> filesystem. Even in this case the mount helper blocks until the
> connection happened. The block time is not negligible, even tough
> not long as a device timeout ...

Well, the mount tool doesn't wait for the network to be configured or
so. It just waits for a response from the server. That's quite a
difference.

> > Well, it's not really ugly. I mean, if the state or properties of a
> > device change, then udev should update its information about it, and
> > that's done via a retrigger. We do that all the time already, for
> > example when an existing loopback device gets a backing file assigned
> > or removed. I am pretty sure that loopback case is very close to what
> > you want to do here, hence retriggering (either from the kernel side,
> > or from userspace), appears like an OK thing to do.
> 
> What seems strange to me is that in this case the devices don't have changed their status.
> How this problem is managed in the md/dm raid cases ?

md has a daemon mdmon to my knowledge.

Lennart

-- 
Lennart Poettering, Red Hat