All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: dhowells@redhat.com, Dave Chinner <david@fromorbit.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Date: Fri, 18 Nov 2016 18:04:16 +0000	[thread overview]
Message-ID: <7019.1479492256@warthog.procyon.org.uk> (raw)
In-Reply-To: <1479489454.7629.1.camel@poochiereds.net>

Jeff Layton <jlayton@poochiereds.net> wrote:

> > We've already been through that.  I wanted to call it stx_data_version but
> > that got argued down to stx_version.  The problem is that what the version
> > number means is entirely filesystem dependent, and it might not just reflect
> > changes in the data.
> > 
> 
> It had better not just reflect data changes.
> 
> knfsd populates the NFSv4 change attribute from inode->i_version. It
> _must_ have changed between subsequent queries if either the data or
> metadata has changed (basically whenever you would update either the
> ctime or the mtime).

No, I think it *should* just reflect the data changes - otherwise you have
have to burn your cached data unnecessarily.

> > > So if stx_version this is intended to export the internal filesystem
> > > inode change counter (i.e. inode->i_version) then lets call it that:
> > > stx_modification_count. It's clear and unambiguous as to what it
> > > represents, especially as this counter is more than just a "data
> > > modification" counter - inode metadata modifications will also
> > > cause it to change....
> > 
> > I disagree that it's unambiguous.  It works like mtime, right?
> 
> More like ctime + mtime mashed together.

Isn't ctime updated every time mtime is?  In which case stx_change_count would
be a better name.

> > Which wouldn't be of use for certain filesystems.  An example of this
> > would be AFS, where it's incremented by 1 each time a write is committed,
> > but is not updated for metadata changes.  This is what matters for data
> > caching.
> > 
> 
> No. Basically the rules are that if something in the inode data or
> metadata changed, then it must be a "larger" value (also accounting for
> wraparound). So you also need to change it (usually by incrementing it)
> when doing namespace changes that involve it (renames, unlinks, etc.).

That's entirely filesystem dependent.

A better rule is that if you do a write and then compare the data version you
got back to the version you had before; if it's increased by exactly one,
there were no other writes between your last retrieval of the attributes and
your write that just got committed.  Admittedly, this assumes that the server
serialises writes to a particular file.

If the value just increases, you don't know that didn't happen by this
mechanism, so the version is of limited value.

> Adding new fields in later piecemeal patches allows us to demonstrate
> that that concept actually works.

You're probably right, but the downside is that we really need some way to
find out what's supported.  On the other hand, we probably need that anyway,
hence my suggestion of an fsinfo() syscall also.

> > You really think we're going to have accurate timestamps with a resolution
> > of a millionth of a nanosecond?  This means you're going to be doing a
> > 64-bit division every time you want a nanosecond timestamp.
> ...
> 
> Could contemporary machines get away with just shifting down by 32
> bits?

A better way would probably be to have:

	struct timestamp {
		__u64 seconds;
		__u32 nanoseconds;
		__u32 femtoseconds;
	};

where you effectively add all the fields together with appropriate
multipliers.

But I still wonder if we really are going to move to femtosecond timestamps,
given that that's going to involve clock frequencies well in excess of 1 THz
to be useful.  Even attoseconds is probably unnecessary, given that clock
frequencies don't seem to be moving much beyond a few GHz, though it's
reasonable that we could have a timestamp counter that has an attosecond
period - it's just that the processing time to deal with it seems likely to
render it unnecessary.

David

  parent reply	other threads:[~2016-11-18 18:04 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells
2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells
2016-11-17 18:39   ` Jeff Layton
2016-11-18  2:32     ` Andreas Dilger
2016-11-18  8:59     ` David Howells
2016-11-18  8:59       ` David Howells
2016-11-18  9:25       ` Andreas Dilger
2016-11-18  9:25         ` Andreas Dilger
2016-11-17 23:40   ` Dave Chinner
2016-11-18  3:28     ` Andreas Dilger
2016-11-18 22:07       ` Dave Chinner
2016-11-18 22:54       ` David Howells
2016-11-19 22:43         ` Dave Chinner
2016-11-21 14:30         ` One Thousand Gnomes
2016-11-21 20:43           ` Dave Chinner
2016-11-22 10:39         ` David Howells
2016-11-22 13:55           ` Jeff Layton
2016-11-22 20:58           ` Dave Chinner
2016-11-18  9:53     ` David Howells
2016-11-18  8:48   ` David Howells
2016-11-18 12:01     ` Jeff Layton
2016-11-18  9:36   ` David Howells
2016-11-18 17:17     ` Jeff Layton
2016-11-18 18:04     ` David Howells [this message]
2016-11-18 18:54       ` Jeff Layton
2016-11-18 19:08       ` David Howells
2016-11-18  9:43   ` David Howells
2016-11-18 21:41     ` Dave Chinner
2016-11-18 22:24     ` David Howells
2016-11-18 10:29   ` David Howells
2016-11-18 10:29     ` David Howells
2016-11-18 21:27     ` Dave Chinner
2016-11-18 21:48     ` David Howells
2016-11-18 21:48       ` David Howells
2016-11-18 22:17       ` Dave Chinner
2016-11-18 22:17         ` Dave Chinner
2016-11-19 10:21         ` Michael Kerrisk (man-pages)
2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells
2016-11-18  3:30   ` Andreas Dilger
2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells
2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells
2016-11-18  3:34   ` Andreas Dilger
2016-11-18  8:47   ` David Howells
2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes
2016-11-17 15:10 ` Michael Kerrisk
2016-11-17 16:33 ` David Howells
2016-11-17 16:45 ` David Howells
2016-11-17 20:00   ` J. Bruce Fields
2016-11-18  2:30     ` Andreas Dilger
2016-11-18  4:29       ` NeilBrown
2016-11-18 13:41   ` One Thousand Gnomes
2016-11-18 13:49   ` David Howells

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=7019.1479492256@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=david@fromorbit.com \
    --cc=jlayton@poochiereds.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available' \
    /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

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.