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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 14 Sep 2022 09:19:22 +1000 From: "NeilBrown" <neilb@...e.de> To: "J. Bruce Fields" <bfields@...ldses.org> Cc: "Dave Chinner" <david@...morbit.com>, "Jeff Layton" <jlayton@...nel.org>, "Theodore Ts'o" <tytso@....edu>, "Jan Kara" <jack@...e.cz>, adilger.kernel@...ger.ca, djwong@...nel.org, trondmy@...merspace.com, viro@...iv.linux.org.uk, zohar@...ux.ibm.com, xiubli@...hat.com, chuck.lever@...cle.com, lczerner@...hat.com, brauner@...nel.org, fweimer@...hat.com, linux-man@...r.kernel.org, linux-api@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, ceph-devel@...r.kernel.org, linux-ext4@...r.kernel.org, linux-nfs@...r.kernel.org, linux-xfs@...r.kernel.org Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new STATX_INO_VERSION field On Wed, 14 Sep 2022, J. Bruce Fields wrote: > On Tue, Sep 13, 2022 at 11:49:03AM +1000, NeilBrown wrote: > > Invalidating the client cache on EVERY unmount/mount could impose > > unnecessary cost. Imagine a client that caches a lot of data (several > > large files) from a server which is expected to fail-over from one > > cluster node to another from time to time. Adding extra delays to a > > fail-over is not likely to be well received. > > > > I don't *know* this cost would be unacceptable, and I *would* like to > > leave it to the filesystem to decide how to manage its own i_version > > values. So maybe XFS can use the LSN for a salt. If people notice the > > extra cost, they can complain. > > I'd expect complaints. > > NFS is actually even worse than this: it allows clients to reacquire > file locks across server restart and unmount/remount, even though > obviously the kernel will do nothing to prevent someone else from > locking (or modifying) the file in between. I don't understand this comment. You seem to be implying that changing the i_version during a server restart would stop a client from reclaiming locks. Is that correct? I would have thought that the client would largely ignore i_version while it has a lock or open or delegation, as these tend to imply some degree of exclusive access ("open" being least exclusive). Thanks, NeilBrown > > Administrators are just supposed to know not to allow other applications > access to the filesystem until nfsd's started. It's always been this > way. > > You can imagine all sorts of measures to prevent that, and if anyone > wants to work on ways to prevent people from shooting themselves in the > foot here, great. > > Just taking away the ability to cache or lock across reboots wouldn't > make people happy, though.... > > --b. >
Powered by blists - more mailing lists