From: Miklos S. <msz...@in...> - 2004-03-26 08:42:50
|
> 1) Is it possible to write an autofs replacement > based on fuse? If a user program executes an open() command for a > file in a FUSE filesystem, can the user space daemon attached to it > mount a new file system just in time and dispatch the call to it? Very good question! This hasn't been tried yet... Open is too late because mounts are only followed in lookup. So the stat() method, which is called from lookup would be good, but since mount also needs to look up the mountpoint, this would lead to a deadlock. I see no trivial solution. I wonder how automount does it. This needs to be looked at. > 2) What about EAs and ACLs in conjunction with FUSE? Currently there's no support for these. If there is a need, it probably isn't hard to extend the API and the kernel interface. But I haven't used either so I'm not the best person to answer this question. > 3) Which is better? LUFS or FUSE? ;-) Who would believe me if I said LUFS :). Seriously: FUSE has a superior kernel part, there's no question about that. The userspace parts have slightly differing designs, each having merits over the other. For example LUFS has a directory cache, which comes very handy in ftpfs. So I think that both have reasons to live, and since you can use the lufis bridge to run LUFS filesystems with the FUSE kernel module, I see no problem with it. I use sshfs every day, and it's cool :) Miklos |
From: Miklos S. <msz...@in...> - 2004-03-26 09:34:07
|
> > 1) Is it possible to write an autofs replacement > > based on fuse? If a user program executes an open() command for a > > file in a FUSE filesystem, can the user space daemon attached to it > > mount a new file system just in time and dispatch the call to it? > > Very good question! This hasn't been tried yet... Open is too late > because mounts are only followed in lookup. So the stat() method, > which is called from lookup would be good, but since mount also needs > to look up the mountpoint, this would lead to a deadlock. > > I see no trivial solution. I wonder how automount does it. This > needs to be looked at. I looked at automount and it plays tricks. So this is not possible without explicit support in fuse. Again if somebody says this is essential I'll consider adding this feature. Miklos |
From: Miklos S. <msz...@in...> - 2004-03-29 08:32:34
|
> I don't now the Linux VFS internals as well as you probably do. What > do you think of this hackish solution for writing an automounter based > on FUSE: > > On every system call the filesystem does something like this: > > Is the access pointed to some directory in an on-demand mount? If > yes: mount it if not yet done so and dispatch the system call to it, > much the same as your fusexmp.c does. If not: Do some magic stuff > in the virtual file system as desired. If the mount fails always > return EIO or so. Yes this can be done. It's not very nice though. For example if the first operation is 'cd automountpoint', all subsequent operations will have to be through the FUSE fs. The mounting will have no effect on the process which has it's cwd under the mount. > It would be great if FUSE would allow writing of automounters. This > would allow the SMB browsing file system to mount all file systems > with the in-kernel SMB stack. Or the implementation of a browsing > file service based on NFS+SLP which would rely on the fast in-kernel > NFS stack. What is the advantage over using current automount? I think automount can be scripted in any way you like, so it's possible to implement more complex schemes like the above. > > I looked at automount and it plays tricks. So this is not possible > > without explicit support in fuse. Again if somebody says this is > > essential I'll consider adding this feature. > > Yes, I do say it is essential! ;-) > > That way you could sell FUSE as autofs superset to the kernel > maintainers. The question is: is there something that could be done with FUSE which cannot be done with autofs, and which is actually useful. If there's such an application I'm open to extending FUSE. Otherwise it's better to have two specialized but simple filesystems, than one complex all-in-one. > It would be nice if at least EAs would be supported. As an exercise I > hacked up a DAV filesystem based on libneon with fuse today. It works > quite well. I would like to export all server supported DAV attributes > to user space using the EA subsystem. That's why I would like EA > support in FUSE: OK. Can you point me to some documentation about how EAs work? Thanks |
From: Miklos S. <msz...@in...> - 2004-03-29 15:53:24
|
> As far as I can think automount directories may not exist before they > are mounted? This is not optimal for network browsing. You could have a FUSE filesystem which generates a set of symlinks to the autofs directory. Wouldn't that work? It would nicely separate the network discovery and the mounting tasks. > http://acl.bestbits.at/man/man.shtml > > That's some documentation for the userspace part. The kernel space > part is merged in Linux 2.6, you'll probably have to study the > code. The (nearly empty) header file for xattr is > include/linux/xattr.h. The code is in fs/xattr.c. OK. Thanks for the pointer. > Three and a half bugreports for FUSE 1.1: > > 1.) du on files exported by fuse returns always 512G in size. Most likely you don't compile with '-D_FILE_OFFSET_BITS=64'. This should be documented, but it isn't: my fault. > 2.) stat (the shell utility) reports always a ctime == 0, regardless > what I set in the fs driver. Works here. Probably the same problem as the previous. > 3.) The umount C command seems to be a noop on my distribution > (debian) It shouldn't be. It needs root privileges though. Have you checked the return value and errno? > 4.) You might want to document that the shell utility "find" only > recurses down directories with nlinks >= 3 and a size > 0. This is > probably something most people ignore when implementing a file > system with FUSE. Good points. I remember something about find detecting broken filesystems, where nlink is not correct for directories. But it seems it's not very good at it. Thanks, Miklos |
From: Miklos S. <msz...@in...> - 2004-03-30 07:19:08
|
> > > As far as I can think automount directories may not exist before they > > > are mounted? This is not optimal for network browsing. > > > > You could have a FUSE filesystem which generates a set of symlinks to > > the autofs directory. Wouldn't that work? It would nicely separate > > the network discovery and the mounting tasks. > > Symlinks are not as nice as real directories in this situation. A > solution I see however is the following: first mount a fuse-based > browsing file system which creates directories as is needs. Than run > autofs on top of this. Do you think that this is a feasable solution? Yes probably. > The reason is that fusermount -u works only for absolute paths as > mount points and I passed a relative path to it. I fixed this in my > code. It might be sensible however, to fix this in your code as well. It works for me if I pass a relative path to it. However fusermount -u does a lazy unmount only so if there are still references to the filesystem, the program won't exit until those references are gone. Fusermount should have a separate lazy unmount flag, so this doesn't cause confusion. > I just relased the first version of fusedav, my WebDAV filesystem > using FUSE. Great, thanks! > You might want to add it to your "Filesystems" file. > > http://0pointer.de/lennart/projects/fusedav/ > > Please use the email address mzshfrqni (at) 0pointer (dot) de in the > "Filesystems" file. I'll do that. Miklos |
From: Miklos S. <msz...@in...> - 2004-03-30 15:35:35
|
> It would be nice if at least EAs would be supported. As an exercise I > hacked up a DAV filesystem based on libneon with fuse today. It works > quite well. I would like to export all server supported DAV attributes > to user space using the EA subsystem. That's why I would like EA > support in FUSE: I checked in EA support to CVS. I've not tested it (apart from returning the correct error value if it's not supported by the fs), so I'd like to hear your feedback. Miklos |
From: Miklos S. <msz...@in...> - 2004-03-31 10:39:40
|
> I checked in EA support to CVS. I've not tested it (apart from > returning the correct error value if it's not supported by the fs), so > I'd like to hear your feedback. OK, get/listxattr were broken for the size=0 case. It acutally works now :) Miklos |