On Jan 04, 2008, at 15:54:06, Oliver Neukum wrote:
I don't think it makes sense for the kernel to try to keep track of
hard data dependencies for FUSE filesystems, or to even *attempt* to
auto-suspend them. You should instead allow a privileged program to
initiate a "freeze-and-flush" operation on a particular FUSE
filesystem and optionally wait for it to finish. Then your userspace
would be configured with the appropriate data dependencies and would
stop FUSE filesystems in the appropriate order.
In addition, the kernel would automatically understand
ext3=>loopback=>fuse, and when asked to freeze the "fuse" part, it
would first freeze the "ext3" and the "loopback" parts using similar
mechanisms as device-mapper currently uses when you do "dmsetup
suspend mydev" followed by "echo 0 $SIZE snapshot /dev/mapper/mydev-
base /dev/mapper/mydev-snap-back p 8 | dmsetup load mydev" (IE: when
you create a snapshot of a given device).
Naturally userspace could deadlock itself (although not the kernel)
by freezing a block device and then attempting to access it, but
since the "freeze" operation is limited to root this is not a big
issue. The way to freeze all filesystems safely would be to clone a
new mount namespace, mlockall(), mount a tmpfs, pivot_root() into the
tmpfs, bind-mount the filesystems you want to freeze directly onto
subdirectories of the tmpfs, and then freeze them in an appropriate
order.
Besides which the worst-case is a pretty straightforward non-critical
failure; you might fail to fully sync a FUSE filesystem because its
daemon is asleep waiting on something (possibly even just sitting in
a "sleep(10000)" call with all signals masked). You simply need to
make sure that all tasks are asleep outside of driver critical
sections so that you can properly suspend your device tree.
Cheers,
Kyle Moffett
--
