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] [day] [month] [year] [list]

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

On Dec 14, 2006  11:48 -0500, Trond Myklebust wrote:
> > 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.

So, to confirm - if existing ext3 filesystems only had 32 bits for the
change attribute, but ext4 filesystems had 64 bits, would that be OK?
If the change attribute would wrap in rare cases, it would still satisfy
the inequality check, but the sequential update behaviour would be lost
for that one update and the client may unnecessarily flush its cache,
or in extremely rare cases NOT flush its cache (if it was disconnected
for exactly 2^32 updates).

If there is a hard requirement for 64-bit change attributes then this
wouldn't be possible without forcing a reformat and update to ext4
with large inodes.

> 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.

What API do you think would be good for getting the change attribute?
I was thinking using i_version for this would be appropriate, since
that is used for the same function already (internal revalidation of
an inode after a lock was dropped temporarily).  It would need to be
extended to 64 bits in size (if you can convince the rest of the
kernel developers about this) or alternately an export_operations method
and the filesystem stores the 64-bit version in its inode_info?

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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