On Mon, 13 Sep 2010 08:01:18 +0200 Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Mon, 13 Sep 2010, Aneesh Kumar K. V wrote: > > As per your suggestion i started looking at handlefs details and below > > is my take on the approach. > > > > handlefs would be an internal kernel mount like pipefs and would have > > inode object mapping to the returned file descriptor of > > open_by_handle_at syscall for symlinks. For regular files we can do what > > we already does and for symlinks we will create inodes in handlefs and > > their inode operation will in turn result in call out of inode operations > > of the actual symlinks. Based on the above > > > > a) We still need open_by_handle_at syscall > > b) We still need handle based link syscall, because we need to support > > creating hardlinks based on handle, and the existing linkat syscall > > takes the oldpath name. > > c) We still need handle based readlink syscall, because the existing > > readlinkat syscall takes pathname. > > You can implement ->read() on the symlink file instead. I would suggest that is a much uglier hack than changed readlinkat to accept a NULL pathname. NeilBrown > > > d) we can drop stat, chown and xattr syscall because they are introduced > > specially for symlinks as we don't allow open on symlinks. > > e) It would be nice to have handle based stat syscall to avoid two > > syscall overhead for fetching file attributes when implementing a > > file server, where fetching file attribute is a common operation. > > Syscall overhead is generally insignificant compared to other effects. > The server can also cache open files for commonly used handles. > > > > > With the above from the current patch series we can drop chown and > > xattr syscalls. Would it be ok if we get the series with the those two > > syscall patches dropped upstream as i work on supporting symlinks with > > handlefs approach ? > > Try it. > > Al seems to only be active to the outside world around the merge > window, so that's the best time to ask him to pull. > > Thanks, > Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
