--- Hans Reiser <[EMAIL PROTECTED]> wrote: > Please treat at greater length how your proposal > differs from NFS.
I think NFS is not flexible enough because: 1) NFS requires synchronization of passwd files or NIS/LDAP to authenticate users (which themselves require root access on both server and client to install) 2) NFS by definition understands only its own network protocol. 3) NFS requires root privileges on the client to mount. I'm not aware of a way to let normal users mount an NFS partition other than listing it in the client's fstab and adding the 'users' option... but then changing fstab still requires root access. 4) Users have to contact their sysadmin every time they want to mount a different partition, a different subdirectory of the same partition, or if they want to change the local mountpoint, all because the partition and mountpoint are hard-coded in fstab. On the other hand, I envision the following: 1) No authentication layer required other than the authentication built into the protocol. All the user needs is the DNS/IP address of the server, a username, a password, a path on the server, and a local directory they own to act as a mountpoint. Note that the user's identity on the server is not tied to his identity on the client, as it is the case with NFS, but rather the user can chose which username to "Connect As" when he performs the mount. 2) Support for multiple network protocols. 3) No need for root privileges when choosing what to mount and where to mount. Some may say this is a security risk, but I see it as improved usability. After all, DE-level implementations like KDE's fish:/ don't require root privileges either. Nevertheless, I think there should be some sort of switch where the sysadmin can allow/deny user mounting on a global or per user basis (rather than a per fstab-line basis). Reasons 3 and 4 for why NFS is not flexible enough could also apply to the current Linux implementation of smbfs, which leads me to believe that part of the problem lies in the fact that users can't mount locations that aren't explicitly listed in fstab. I guess a per fstab-line basis of allowing mounts makes sense when there are a finite number of devices, but it doesn't make much sense when there are an infinite number of network addresses. I'm just thinking out loud here, but would it be possible to specify ranges of addresses and directories using wildcards? Such a line in fstab would look like: *.myhost.com:/home/* /home/* nfs rsize=8192,wsize=8192,timeo=14,users In this case, users could do: mount -t nfs host1.myhost.com:/home/username ~/remote_home but they couldn't do: mount -t nfs host1.myhost.com:/tmp ~/remote_tmp After receiving several suggestions, it appears that FUSE (http://fuse.sourceforge.net/) and the various projects that build on it (http://fuse.sourceforge.net/filesystems.html) have the potential to do a lot of what I had envisioned LODNA doing. Therefore, I realize that there's probably no need for yet another VFS framework ;) Nevertheless, I think there is room for improvement when it comes to giving users more flexibility in mounting network locations (as described above). Thanks, Vlad __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
