From: Tyler F. <ty...@pa...> - 2012-06-21 16:43:11
|
First and foremost a sincere thank you is in order. Fuse is a fantastic product that has drastically empowered our business and expanded the possibilities of virtual filesystems. In short, thank you. I'm not here to report a bug per se, but perhaps try to enlist some advice as to how I might be able to patch the fuse adapter to cater to our specific needs. The problem resides within the force umount behavior. Here's the problem: We are a hosting company and leverage lxc and openvz container virtualization (linux vps slices basically). We also have a distributed gluster storage cluster where clients can store files that need to be distributed across all vps instances. We are using the glusterfs fuse adapter to access these files. Each fuse connection requires approximately 20MB of RAM, which, adds up when we have hundreds of containers per server. Not to mention the complexity of monitoring each individual mount point. So instead, we create a mount on the host machine to the parent directory of all our clients files. Then, individually, we bind mount subdirectories into their respective chrooted environments. This actually works extremely well. Not only is it very performant, but we only have to monitor one mount. Once the parent mount is restored, all the sub bind mounts recover as well. There is only one problem, which I'll readily admit is a unique problem that probable doesn't make sense to other fuse users. The problem relies in the umount behavior. If a umount -f occurs on a subdirectory of the of the fuse mount which is bind mounted, the parent mount (fuse mount) suddenly reports "Transport Endpoint Not Connected". Which also propagates to each of the submounts as well. The first problem is that I'm not completely sure why that happens. I've been trying to sift through the source code and admittedly I'm struggling to pinpoint the specific behavior. It was my assumption that bind mounts were independent mount types that did not try to inherit from parent mounts. Either way, it is apparent that any submounts inherit the the session from the parent. As such, that becomes problematic if a guest os tries to umount with a --force flag. I'm having a difficult time pinpointed where that behavior is found as well. What I do know is that a force umount immediately kills the session. That much I know from looking at the release notes in the project. Apparently it's a feature, which makes sense in all other cases. In the newest stable tar ball I'm unable to find any logic that responds directly to a FORCE flag. Ultimately I just want to find the logic and remove it for our case. Any help on locating this logic would be greatly appreciated. Thanks Tyler |
From: Miklos S. <mi...@sz...> - 2012-06-28 16:51:20
|
Tyler Flint <ty...@pa...> writes: > First and foremost a sincere thank you is in order. Fuse is a > fantastic product that has drastically empowered our business and > expanded the possibilities of virtual filesystems. In short, thank > you. > > I'm not here to report a bug per se, but perhaps try to enlist some > advice as to how I might be able to patch the fuse adapter to cater to > our specific needs. The problem resides within the force umount > behavior. Here's the problem: We are a hosting company and leverage > lxc and openvz container virtualization (linux vps slices > basically). We also have a distributed gluster storage cluster where > clients can store files that need to be distributed across all vps > instances. We are using the glusterfs fuse adapter to access these > files. Each fuse connection requires approximately 20MB of RAM, which, > adds up when we have hundreds of containers per server. Not to mention > the complexity of monitoring each individual mount point. So instead, > we create a mount on the host machine to the parent directory of all > our clients files. Then, individually, we bind mount subdirectories > into their respective chrooted environments. This actually works > extremely well. Not only is it very performant, but we only have to > monitor one mount. Once the parent mount is restored, all the sub bind > mounts recover as well. > > There is only one problem, which I'll readily admit is a unique > problem that probable doesn't make sense to other fuse users. The > problem relies in the umount behavior. If a umount -f occurs on a > subdirectory of the of the fuse mount which is bind mounted, the > parent mount (fuse mount) suddenly reports "Transport Endpoint Not > Connected". Which also propagates to each of the submounts as well. > > The first problem is that I'm not completely sure why that > happens. I've been trying to sift through the source code and > admittedly I'm struggling to pinpoint the specific behavior. It was my > assumption that bind mounts were independent mount types that did not > try to inherit from parent mounts. Either way, it is apparent that any > submounts inherit the the session from the parent. As such, that > becomes problematic if a guest os tries to umount with a --force > flag. I'm having a difficult time pinpointed where that behavior is > found as well. What I do know is that a force umount immediately kills > the session. That much I know from looking at the release notes in the > project. Apparently it's a feature, which makes sense in all other > cases. In the newest stable tar ball I'm unable to find any logic that > responds directly to a FORCE flag. Ultimately I just want to find the > logic and remove it for our case. Any help on locating this logic > would be greatly appreciated. MNT_FORCE is handled in fs/namespace.c:do_umount(). It calls the filesystems' umount_begin() operation which is fs/fuse/inode.c:fuse_umount_begin() in this case. Hope that helps. Thanks, Miklos |