All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Andreas Dilger <adilger@sun.com>
Cc: Mark Fasheh <mfasheh@suse.com>,
	linux-fsdevel@vger.kernel.org, Sage Weil <sage@newdream.net>,
	Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: Re: [PATCH 1/2] [RFC] vfs: 'stat light' fstatat flags
Date: Tue, 7 Apr 2009 19:13:15 +0100	[thread overview]
Message-ID: <20090407181313.GG31824@shareable.org> (raw)
In-Reply-To: <20090407174821.GU3204@webber.adilger.int>

Andreas Dilger wrote:
> > > Instead, as was proposed in the last generation of this thread,
> > > there should be
> > > AT_GET_{ATIME,MTIME,CTIME,BLOCKS,SIZE,NLINKS,...}, to return the
> > > flags that the application actually wants.
> > 
> > Well, I respectfully disagree. In my opinion, this adds unncessary
> > complexity to an already targetted case, where only a handful of
> > file systems will even care to optimize away a couple of
> > fields. In that light, I really think we want simplicity here.
> 
> The difficult part is that the application knows which fields it is going
> to use, and the filesystem knows which fields are expensive to fill in,
> and by merging multiple fields together you are deciding arbitrarily that
> you know better than either.  The main users will be common tools like
> "ls --color" and "find", and they know exactly which fields are needed,
> but they need to do a LOT of stats so making it efficient is worthwhile.

I agree with Andreas.  The issue isn't "what is efficient and simple (now)",
but what makes a good future-compatible interface.

> > The good news is that we still have a
> > very good amount of space in the flags field. We could always go back if we
> > _really_ find the need to micro-optimize to the point of per stat field
> > flags. Again though, at this point I don't really think starting out with a
> > slew of flags is a good idea.
> 
> Similar to the helper macros for S_IRWXU = (S_IRUSR|S_IWUSR|S_IXUSR)
> applications won't necessarily need to specify all flags explicitly.

Yes.

If it's intended to re-use the fstatat system call for this, the
conversion from "no stat field flags" to AT_STAT_ALL should be done in
the general fstatat code.

fstatat() is for doing stat() or lstat() relative to an open
directory.  (Anyone else thing the name is stupid - why isn't it
statat like openat, etc.?)

So how do you do a selective fstat() - attributes of an open file?
Don't waste a flag, and just specify AT_SELF as the pathname value to
mean return the attributes of the fd argument itself.  AT_SELF would
be NULL, or perhaps (const char *) -1 to catch application errors.

-- Jamie

  reply	other threads:[~2009-04-07 18:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07  8:00 [PATCH 1/2] [RFC] vfs: 'stat light' fstatat flags Mark Fasheh
2009-04-07 10:23 ` Andreas Dilger
2009-04-07 14:59   ` Oleg Drokin
2009-04-07 15:18   ` Sage Weil
2009-04-07 15:29   ` Mark Fasheh
2009-04-07 17:52     ` Andreas Dilger
2009-04-07 18:13       ` Jamie Lokier [this message]
2009-04-07 23:13   ` Russell Cattelan
2009-04-07 17:42 ` Jamie Lokier
2009-04-07 17:48   ` Oleg Drokin
2009-04-07 18:16     ` Jamie Lokier
2009-04-07 18:24       ` Oleg Drokin
2009-04-07 20:37         ` Trond Myklebust
2009-04-08 18:48           ` Jamie Lokier
2009-04-09 15:13             ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090407181313.GG31824@shareable.org \
    --to=jamie@shareable.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=adilger@sun.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mfasheh@suse.com \
    --cc=sage@newdream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.