On 2015-06-15 12:46, Lennart Poettering wrote: > On Sat, 13.06.15 17:09, Goffredo Baroncelli (kreij...@libero.it) wrote: > >>> Further, the problem will be more intense in this eg. if you use dd >>> and copy device A to device B. After you mount device A, by just >>> providing device B in the above two commands you could let kernel >>> update the device path, again all the IO (since device is mounted) >>> are still going to the device A (not B), but /proc/self/mounts and >>> 'btrfs fi show' shows it as device B (not A). >>> >>> Its a bug. very tricky to fix. >> >> In the past [*] I proposed a mount.btrfs helper . I tried to move the logic >> outside the kernel. >> I think that the problem is that we try to manage all these cases >> from a device point of view: when a device appears, we register the >> device and we try to mount the filesystem... This works very well >> when there is 1-volume filesystem. For the other cases there is a >> mess between the different layers: > >> - kernel >> - udev/systemd >> - initrd logic >> >> My attempt followed a different idea: the mount helper waits the >> devices if needed, or if it is the case it mounts the filesystem in >> degraded mode. All devices are passed as mount arguments >> (--device=/dev/sdX), there is no a device registration: this avoids >> all these problems. > > Hmm, no. /bin/mount should not block for devices. That's generally > incompatible with how the tool is used, and in particular from > systemd. We would not make use for such a scheme in > systemd. /bin/mount should always be short-running.
Apart systemd, which are these incompatibilities ? > > I am pretty sure that if such automatic degraded mounting should be > supported, then this should be done with some background storage > daemon that alters the effect of the READY ioctl somehow after the > timeout, and then retriggers the devcies so that systemd takes > note. (or, alternatively: such a scheme could even be implemented all > in kernel, based on some configurable kernel setting...) I recognize that this solution provides the maximum compatibility with the current implementation. However it seems too complex to me. Re-trigging a devices seems to me more a workaround than a solution. Could a generator do this job ? I.e. this generator (or storage daemon) waits that all (or enough) devices are appeared, then it creates a .mount unit: do you think that it is doable ? > > Lennart > Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
