linux-ext4 - Re: [RFC] [patch 2/3] change attribute for ext4: ext4 specific code

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:03:07 -0500
From:	Theodore Tso <tytso@....edu>
To:	Cordenner jean noel <jean-noel.cordenner@...l.net>
Cc:	Andreas Dilger <adilger@...sterfs.com>, linux-ext4@...r.kernel.org
Subject: Re: [RFC] [patch 2/3] change attribute for ext4: ext4 specific code

On Wed, Dec 13, 2006 at 06:31:50PM +0100, Cordenner jean noel wrote:

There was discussion on yesterday's call about whether or not 32-bit
was enough for NFSv4, or whether it also requried 64-bits of change
notification in the RFC's.  So one of the questions is whether this is
something that would justify requiring 64-bits --- and if so, maybe we
need to require that big inodes be used and store the entire 64-bit
value beyond 128 bytes.  This would mean that NFSv4 cache management
couldn't be fully implemented without big inodes, or we'd have to make
do by using the inode ctime as a partial substitute.

What do you think?

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