[PATCHES] - Statlite Support in Samba/GPFS vfs

[Jeremy Allison]

On Tue, Sep 30, 2014 at 03:49:59PM +0200, Volker Lendecke wrote:
> On Tue, Sep 30, 2014 at 04:38:29PM +0530, Shekhar Amlekar wrote:
> > Please find attached patches that implement statlite support in Samba and 
> > gpfs vfs. Would you please review and let me know any comments/suggestions 
> > that you may have.
> 
> In general, the patches look good, thanks for that!
> 
> > It is known that in clustered file systems, a writer on a node can be 
> > slowed down significantly by exact stat calls happening on other nodes. A 
> > partial stat, wherever sufficient, helps in such cases. For this purpose, 
> > we have support for (l)statlite() in gpfs, that we would like to make use 
> > of.
> > 
> > I've defined following vfs entry points -
> > 
> > statlite(handle, dirfd, smb_fname, atflag, slitemask);
> > fstatlite(handle, fsp, sbuf, slitemask);
> > 
> > The existing stat/lstat/fstat calls in Samba can be mapped onto above lite 
> > variants wherever required, Later, if fstatatlite becomes available, it'd 
> > be possible to map the fstatat to statlite vfs call using the dirfd. I'm 
> > identifying places in the code where these lite calls can be utilized - 
> > and can post those patches later.
> 
> Before we put the VFS changes in, I'd like to see some of
> the users of the calls. The one very obvious call is in
> unix_convert for directories that we just traverse. Here we
> don't care about any metadata except whether the name exists
> and whether it's a directory or something else. Apart from
> that I think we need to take a close look. For example we
> might be able to avoid asking for the write timestamp for
> files we do have open. There we tend to store the values we
> have to report in locking.tdb. What we don't store is the
> current file size, so we have to ask for that. It would be
> interesting to know from the GPFS people whether we gain
> anything by asking only for precise st_size but not for
> st_mtime. GPFS might have to pull the inode data anyway if
> we have to ask for one precise field. Is GPFS finegrained
> enough here?
> 
> This might also revive the discussion that was mentioned
> http://lwn.net/Articles/394298/ about Linux xstat. I think
> that never went anywhere, or am I missing something?

I agree with Voker's assessment. Before we freeze something
like this into the VFS it'd be good to see at least another
underlying filesystem implementation so we have a chance
to get the interface close to right.

Do any *BSD's have a stat-light implementation ? Any
of the Linux cluster FS's (gluster/ceph/lustre) ?

Jeremy.