|
From: Anton A. <ai...@ca...> - 2003-04-23 12:43:30
|
On Wed, 23 Apr 2003, Szakacsits Szabolcs wrote: > On Tue, 22 Apr 2003, Anton Altaparmakov wrote: > > Nobody ever expressed interessed in it which is why noone ever bothered > > working on it... Now that someone is interested I will consider working > > on this in the near-ish future. But note that we may well only do it for > > 2.5.x kernels as 2.4.x kernels handle nfs completely differently (unless > > I've looked 2.4.20 _quickly_ at that time. nfsd/export.c states > > /* There are two requirements on a filesystem to be exportable. > * 1: We must be able to identify the filesystem from a number. > * either a device number (so FS_REQUIRES_DEV needed) > * or an FSID number (so NFSEXP_FSID needed). > * 2: We must be able to find an inode from a filehandle. > * either using fh_to_dentry (prefered) > * or using read_inode (the hack). > */ > > The new ntfs driver satisfies both, still it's not exportable. However I > didn't look it further why. You have to define a structure to enable this to happen explicitly. That is easy if you use the default nfs provided operations... > > To implement properly pretty much impossible as there just isn't enough > > You mean for a read-write ntfs driver? IMHO that's a bit far ... For the > read-only one it's much-much more simpler. No. Read-only is affected in the same way. I can't quite remember the details any more but I think it was something along the lines of: Because of hard links and short/long/posix file names it is impossible to find the path to an inode only given the inode and this is precisely what we need to be able to do. (I may be remembering wrong... but something like that was the reason.) The need arises when an nfs server restarts while the client has a file open. The next access to the server then needs to reestablish the open file which for ntfs is impossible to do accurately. Anton |
