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. > 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
