On Wed, Aug 28, 2019 at 09:57:25AM -0400, Chuck Lever wrote: > > > > On Aug 28, 2019, at 9:51 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > On Wed, 2019-08-28 at 09:48 -0400, bfields@xxxxxxxxxxxx wrote: > >> On Tue, Aug 27, 2019 at 03:15:35PM +0000, Trond Myklebust wrote: > >>> I'm open to other suggestions, but I'm having trouble finding one that > >>> can scale correctly (i.e. not require per-client tracking), prevent > >>> silent corruption (by causing clients to miss errors), while not > >>> relying on optional features that may not be implemented by all NFSv3 > >>> clients (e.g. per-file write verifiers are not implemented by *BSD). > >>> > >>> That said, it seems to me that to do nothing should not be an option, > >>> as that would imply tolerating silent corruption of file data. > >> > >> So should we increment the boot verifier every time we discover an error > >> on an asynchronous write? > >> > > > > I think so. Otherwise, only one client will ever see that error. > > +1 > > I'm not familiar with the details of how the Linux NFS server > implements the boot verifier: Will a verifier bump be effective > for all file systems that server exports? Yes. It will be per network namespace, but that's the only limit. > If so, is that an acceptable cost? It means clients will resend all their uncommitted writes. That could certainly make write errors more expensive. But maybe you've already got bigger problems if you've got a full or failing disk? --b.
