This is the mail archive of the
mailing list for the glibc project.
Re: Extended file stat: Splitting file- and fs-specific info?
- From: Bernd Schubert <bernd dot schubert at itwm dot fraunhofer dot de>
- To: Andreas Dilger <adilger at dilger dot ca>
- Cc: Christoph Hellwig <hch at infradead dot org>, David Howells <dhowells at redhat dot com>, Dave Chinner <david at fromorbit dot com>, bfields at fieldses dot org, smfrench at gmail dot com, ben at decadent dot org dot uk, Trond dot Myklebust at netapp dot com, roland at hack dot frob dot com, jra at samba dot org, linux-fsdevel at vger dot kernel dot org, linux-nfs at vger dot kernel dot org, linux-cifs at vger dot kernel dot org, samba-technical at lists dot samba dot org, linux-ext4 at vger dot kernel dot org, linux-api at vger dot kernel dot org, libc-alpha at sourceware dot org
- Date: Wed, 09 May 2012 16:12:57 +0200
- Subject: Re: Extended file stat: Splitting file- and fs-specific info?
- References: <20120509002420.GL5091@dastard> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20120509111958.GA11345@infradead.org> <4FAA5B24.firstname.lastname@example.org> <20120509120544.GA17535@infradead.org> <4FAA6230.email@example.com> <F6D8E5E4-D187-4EE6-8827-6BB90BE6E8BC@dilger.ca>
On 05/09/2012 03:51 PM, Andreas Dilger wrote:
On 2012-05-09, at 6:25 AM, Bernd Schubert wrote:
On 05/09/2012 02:05 PM, Christoph Hellwig wrote:
On Wed, May 09, 2012 at 01:55:16PM +0200, Bernd Schubert wrote:
The basic idea of generation numbers is to check if an inode was
recycled, so only if the tuple of inode-number and generation-number
matches we still have the same file. Kernel nfs
NFS does not and should not look at the inode generation. Except for a
bit of legacy code for the old pre-Linux 2.4 filehandles it looks at the
opaque file handle returned and only interpreted by the filesystem. Any
userspace NFS server should do the same.
Ok, I didn't look how kernel NFS does it for quite some time already...
User space NFS only can do it beginning with 2.6.39 - given that user space also needs to support older kernels and other OSs, which might not have open_by_handle, userspace unfortunately cannot entirely rely on that feature.
But even fewer kernels have sys_statxat() in them (i.e. none), so you can rely on that even less than open_by_handle()...
Well, I didn't say that :) In summary, an application needs to try to
use the open-by-handle call and if that is not supported, it has to fall
back to traditional stat and generation-number-ioctl. And as I said
before, open-by-handle very likely removes the requirement for
generation numbers in sys_statxat().