> > Why can't the device just be encoded in the filehandle?
> >
> Because the current scheme is based on the the client getting the original
> file handle (with the device information et al.) from mountd.
> Obviously, if you just cross a mount point on the server, the client
> doesn't actually mount the subvolume.
With unfsd, if /usr and /usr/local are on different devices, you can
export the entire /usr tree including /usr/local simply by exporting /usr.
Try it. /usr/local doesn't even have to be on a local drive. So obviously
unfsd employs a scheme that makes this work and does so by putting the
necessary information in the open file handles it passes to the client.
Apparently there is a performance issue or something else preventing knfsd
from doing the same, possibly because it's chosen to track things by
actual device and inode, rather than by mapping file handles to pathnames
or whatever unfsd does. It's a rather hefty piece of functionality to give
up for performance, and I'm not quite sure why we can't work around this
limitation.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/