'Twas brillig, and Lennart Poettering at 24/01/14 17:43 did gyre and gimble: >> > For me personally, the NFS timeout is a proper pain the backside. A >> > little more cleverness there would be appreciated. e.g. can we not just >> > do lazy umounts by default for NFS (or just e.g. a 5s timeout max on the >> > regular NFS umount)? Perhaps this isn't possible in the umount loop - or >> > at least not possible cleanly... > We used to do that in the final umount loop. But that doesn't really > work, since the loop relies that busy file systems return EBUSY if they > are busy... > > Mounts need proper depdendency so that we cann unmount them. THere's no > way around that really...
There has to be a way around dealing with the NFS case. It's surely quite common - certainly it's one I have to deal with a lot. That said, it's maybe something to solve in the NFS code better, as I often resume from suspend to a different network and only really notice my old NFS mounts are still there when I try to use a file->open dialog which just hangs (as does e.g. "df") if you have such stale mounts and never seems to recover. Either way, some better way of handling of this really needs to go in somewhere in the stack! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
