On 2017-05-02 20:49, Adam Borowski wrote: >> It could be some daemon that waits for btrfs to become complete. Do we >> have something? > Such a daemon would also have to read the chunk tree.
I don't think that a daemon is necessary. As proof of concept, in the past I developed a mount helper [1] which handled the mount of a btrfs filesystem: this handler first checks if the filesystem is a multivolume devices, if so it waits that all the devices are appeared. Finally mount the filesystem. > It's not so simple -- such a btrfs device would have THREE states: > > 1. not mountable yet (multi-device with not enough disks present) > 2. mountable ro / rw-degraded > 3. healthy My mount.btrfs could be "programmed" to wait a timeout, then it mounts the filesystem as degraded if not all devices are present. This is a very simple strategy, but this could be expanded. I am inclined to think that the current approach doesn't fit well the btrfs requirements. The roles and responsibilities are spread to too much layer (udev, systemd, mount)... I hoped that my helper could be adopted in order to concentrate all the responsibility to only one binary; this would reduce the interface number with the other subsystem (eg systemd, udev). For example, it would be possible to implement a sane check that prevent to mount a btrfs filesystem if two devices exposes the same UUID... BR G.Baroncelli [1] See "[RFC][PATCH v2] mount.btrfs helper" thread ( https://marc.info/?l=linux-btrfs&m=141736989508243&w=2 ) -- 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
