[PATCH] Statlite - without VFS changes

[Jeremy Allison]

On Fri, Dec 19, 2014 at 03:03:20PM -0500, Simo wrote:
> On Fri, 2014-12-19 at 10:36 -0800, Jeremy Allison wrote:
> > On Fri, Dec 19, 2014 at 12:43:29PM +0530, Shekhar Amlekar wrote:
> > > Hi,
> > > 
> > > Few days back I submitted a stat-lite patch that proposed a
> > > new samba VFS call and hence needed changes to few
> > > VFS modules. Here's an attempt to implement the functionality
> > > without making changes to Samba VFS. The interface is as
> > > follows-
> > > 
> > > The statlite mask (in stat structure) is always populated by
> > > Samba before making a stat call and entering the VFS. For
> > > normal stat calls, all the bits are set and for partial stats, only
> > > the select bits are set. Samba also updates the mask, after
> > > the call.(1)
> > > 
> > > The opaque VFS modules that support statlite functionality
> > > (currently vfs_gpfs) read the mask and retrieve requested
> > > attribs. If all the requested attribs can't be retrieved, an error
> > > is returned. (2)
> > > 
> > > Because of (1) and (2), no changes are required to the
> > > opaque modules that do not support statlite functionality.
> > > They overwriting the mask field would cause no harm
> > > (vfs_ceph and vfs_glusterfs zero out the stat structure).
> > > 
> > > Request your kind review.
> > 
> > Unfortunately the SMB_STRUCT_STAT is implicitly part of the VFS
> > interface, so this still means a VFS change.
> 
> Would it be a good time to make it (all or partially) opaque, so we stop
> having to bump the VFS interface for internal changes ?

Doing that to a STAT struct would be *really* hard.
We'd need to replace all direct access (e.g. pst->st_ex_uid)
with accessor functions. Not sure it's worth it. The
STAT struct really changes very rarely.