linux-ext4 - Re: rfc: [patch] change attribute for ext3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Dec 2006 11:48:09 -0500
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	Andreas Dilger <adilger@...sterfs.com>,
	Alexandre Ratchov <alexandre.ratchov@...l.net>,
	linux-ext4@...r.kernel.org, nfsv4@...ux-nfs.org
Subject: Re: rfc: [patch] change attribute for ext3

On Wed, 2006-12-13 at 20:52 -0500, J. Bruce Fields wrote:
> > What kind of requirements does NFSv4 place on the version?  Monotonic is
> > probably a good bet.
> 
> The only requirement is that it be unique (assuming a file is never
> modified 2^64 times).  Clients can't compare them except for equality.

The other requirement is that they be updated in more or less any
situation where you would normally see a 'ctime' update. In other words
any time when the file metadata or data changes, and any time when the
ACL changes.

(NB: I'm not sure what we should do w.r.t. xattr changes since those are
not really covered by RFC3530.)

Atomicity is not a hard requirement, however the server is required to
know whether or not the update was atomic. If the update is atomic, a
careful client may perform certain optimisations based upon it knowing
that no other changes to the inode have raced with this one. For
instance, if it knows that a file creation atomically updated the change
attribute of the directory, then it can determine that it does not need
to check for other changes to that directory.

> > Does it need to be global for the filesystem
> 
> Nope.
> 
> > or is a per-inode version sufficient?
> 
> Yes.

Yes. If your filesystem wants to support Solaris or Reiser4-like
subfiles, then it is expected that each subfile should have its own
change attribute (whereas changes to the subfile 'directory' will be
reflected by the parent inode's change attribute.

Change attribute values may be reused if the inode number is reused (as
long as the filesystem has something like a generation counter that
allows it to distinguish between different instances of the same inode
number).

> > What functionality of NFSv4 needs the version?
> 
> Clients use it to revalidate their caches.

Yup. It is used to detect changes made on the NFS server itself
(possibly by other NFS clients, possibly by local processes on the
server), so that the client can flush out any stale cached data.

Cheers
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html