[PATCH] Statlite - without VFS changes

Shekhar Amlekar samlekar at in.ibm.com
Fri Jan 2 02:58:37 MST 2015


> From: Volker Lendecke <Volker.Lendecke at SerNet.DE>
> To: Shekhar Amlekar/India/IBM at IBMIN
> Cc: Ralph Böhme <rb at sernet.de>, samba-technical <samba-
> technical at lists.samba.org>, Jeremy Allison <jra at samba.org>
> Date: 12/29/2014 05:02 PM
> Subject: Re: [PATCH] Statlite - without VFS changes
> 
> On Wed, Dec 24, 2014 at 03:13:51PM +0530, Shekhar Amlekar wrote:
> > The initial patch I floated proposed an interface similar
> > to what you mention -
> > 
> > 
https://lists.samba.org/archive/samba-technical/2014-December/104059.html
> > 
> > However, it required changes to many VFS modules,
> > As you know, there are modules that change path
> > (catia, cap, mh, scannedonly), some that change the
> > stat struct (fake_perms, fake_acls, fruit), and some just
> > audit vfs calls (full audit, time audit). Also, the opaque
> > modules (ceph, glusterfs) needed to handle the new
> > VFS call.
> > 
> > Overall, it became a pretty large patch - so, this is an
> > alternative we are exploring.
> 
> Just brainstorming a bit. This is pretty intrusive, so I'm not 100%
> sure what solution would be right here. What's the main problem we
> want to solve? We want to make SMB requests that trigger STAT calls
> internally less intrusive on the file system. Many places in the code
> don't need precise mtime, in particular the ones where we only need
> static information like the file type (directory/file/socket etc).
> The fact that we only need partial information needs to be obvious at 
the
> caller's site. For example check_parent_exists() does not need any stat
> information at all, it just checks for success. Here the function call
> inside check_parent_exists should make this fact obvious.  This means
> a new VFS call.
> 
> The main reason why I'm interested in a new call is just
> compatibility. STAT is so basic that I'm worried to change it.
> 
> The new call should not touch smb_fname->st but take a sbuf parameter. 
The
> caller might decide to smb_fname->st, but I'm not entirely sure. In
> the very big picture I think adding the stat info to a struct called
> smb_filename was a mistake. We need a separate struct for this, but
> that's something for another day.

Ok, but this is still similar to our option
one. A new VFS call, that takes path as input
and returns partial stat, would need changes
to the VFS modules that change path or static
fields in the stat struct (catia, mh, cap,
scannedonly, fake_perms, fake_acls etc). We
need to see if we are okay to put in these
changes.

On the other hand, in option two, we have
additional interface functions, vfs_path_exists()
and vfs_path_get_partial_stat(), that can
be used by the callers as per their need. The
SMB_VFS_STAT() call is still available for use
where complete stat info is needed. One other
thing that we can do here is to provide a
routine, say vfs_path_get_full_stat(), to
remove the following blocks in the code -

if (lp_posix_pathnames()) {
    ret = SMB_VFS_LSTAT(handle->conn, smb_fname);
} else {
    ret = SMB_VFS_STAT(handle->conn, smb_fname);
}

If all of these instances are replaced some
day, we can get rid of smb_vfs_call_next_stat()
and move the initializing of statlite
mask from smb_vfs_call_stat() to
vfs_path_get_full_stat().

The only other option that's left unexplored is
to send statlite mask as an explicit parameter to
stat/lstat vfs routines (but not to SMB_VFS_STAT()).
Unfortunately, this means changes at all the
places where SMB_VFS_NEXT_STAT() is used, to relay
the mask to the next module.

So, here are the three options I can think of-

-A new VFS call; Need changes to VFS modules
that handle stat/lstat
-stlite_mask as an input inside stat_ex struct
-stlite_mask as an input to stat/lstat
vfs routines
-any other options ?

> 
> A small technical question: Why does the gpfs stat lite call take the
> mask as a pointer? What does it return there? My assumption would be
> that we request precise information and we get it, just as the stat call
> would. Could gpfs return less or more than we asked for?

Yes, it can return more that what we ask for
and the mask would be updated to reflect that.
If we ask for a particular static field in stat
struct, say mode, returning other static fields
is no more work for the file system.

Thanks,
shekhar.


More information about the samba-technical mailing list