On Sat, Jan 27, 2018 at 4:06 AM, Tomasz Pala <gotar@xxxxxxxxxx> wrote: > As for the regular by-UUID mounts: these links are created by udev WHEN > underlying devices appear. Does btrfs volume appear? No. If I boot with rd.break=pre-mount I can absolutely mount a Btrfs multiple volume that has a missing device by UUID with --uuid flag, or by /dev/sdXY, along with -o degraded. And I can then use the exit command to continue the startup process. In fact I can try to mount without -o degraded, and the mount command "works" in that it does not complain about an invalid node or UUID. The Btrfs systemd udev rule is a sledghammer because it has no timeout. It neither times out and tries to mount anyway, nor does it time out and just drop to a dracut prompt. There are a number of things in systemd startups that have timeouts, I have no idea how they get defined, but that single thing would make this a lot better. Right now the Btrfs udev rule means if all devices aren't available, hang indefinitely. I don't know systemd or systemd-udev well enough at all to know if this rule can have a timer. Service units absolutely can have timers, so maybe there's a way to marry a udev rule with a service which has a timer. The absolute dumbest thing that's better than now, is at the timer just fail and drop to a dracut prompt. Better would be to try a normal mount anyway, which also fails to a dracut prompt, but additionally gives us a kernel error for Btrfs (the missing device open ctree error you'd expect to get when mounting without -o degraded when you're missing a device). And even better would be a way for the user to edit the service unit to indicate "upon timeout being reached, use mount -o degraded rather than just mount". This is the simplest of Boolean logic, so I'd be surprised if systemd doesn't offer a way for us to do exactly what I'm describing. Again the central problem is the udev rule now means "wait for device to appear" with no timed fallback. The mdadm case has this, and it's done by dracut. At this same stage of startup with a missing device, there is in fact no fs colume UUID yet because the array hasn't started. Dracut+mdadm knows there's a missing device so it's just iterating: look, sleep 3, look, sleep 3, look, sleep 3. It's on a loop. And after that loop hits something like 100, the script says f it, start array anyway, so now there is a degraded array, and for the first time the fs volume UUID appears, and systemd goes "ahaha! mount that!" and it does it normally. So the timer and timeout and what happens at the timeout is defined by dracut. That's probably why the systemd folks say "not our problem" and why the kernel folks say "not our problem". > If btrfs pretends to be device manager it should expose more states, > especially "ready to be mounted, but not fully populated" (i.e. > "degraded mount possible"). Then systemd could _fallback_ after timing > out to degraded mount automatically according to some systemd-level > option. No, mdadm is a device manager and it has no such facility. Something issues a command to start the array anyway, and only then do you find out if there are enough devices to start it. I don't understand the value of knowing whether it is possible. Just try to mount it degraded and then if it fails we fail, nothing can be done automatically it's up to an admin. And even if you had this "degraded mount possible" state, you still need a timer. So just build the timer. If all devices ready ioctl is true, the timer doesn't start, it means all devices are available, mount normally. If all devices ready ioctl is false, the timer starts, if all devices appear later the ioctl goes to true, the timer is belayed, mount normally. If all devices ready ioctl is false, the timer starts, when the timer times out, mount normally which fails and gives us a shell to troubleshoot at. OR If all devices ready ioctl is false, the timer starts, when the timer times out, mount with -o degraded which either succeeds and we boot or it fails and we have a troubleshooting shell. The central problem is the lack of a timer and time out. > Unless there is *some* signalling from btrfs, there is really not much > systemd can *safely* do. That is not true. It's not how mdadm works anyway. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
