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