[PATCH] Statlite - without VFS changes

[Volker Lendecke]

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.

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?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de