About patch NFS: Fix O_DIRECT accounting of number of bytes read/written

About patch NFS: Fix O_DIRECT accounting of number of bytes read/written

[Su, Yanjun]

Hi trond,
Because My mail system cant receive nfs mail list’s mails, I reply your patch here.
I have some question for the patch.

>No. Basic O_DIRECT does not guarantee atomicity of requests, which is
>why we do not have generic locking at the VFS level when reading and
>writing. The only guarantee being offered is that O_DIRECT and buffered
>writes do not collide.
Do you mean other fs also cant guarantee atomicity of O_DIRECT request or just nfs?

>IOW: I think the basic premise for this test is just broken (as I
>commented in the patch series I sent) because it is assuming a
>behaviour that is simply not guaranteed.
So the generic/465 of xfstests can’t apply to nfs for now, am I right?

>BTW: note that buffered writes have the same property. They are ordered
>when being written into the page cache, meaning that reads on the same
>client will see no holes, however if you try to read from another
>client, then you will see the same behaviour, with temporary holes
>magically appearing in the file.
As you say, nfs buffered write also has the hole problem with multiple r/w on different clients.
I want to know if the problem exists in other local fs such as xfs,ext4?

Thanks in advance.

Re: About patch NFS: Fix O_DIRECT accounting of number of bytes read/written

[Trond Myklebust]

On Wed, 2019-10-16 at 01:00 +0000, Su, Yanjun wrote:
> Hi trond,
> Because My mail system cant receive nfs mail list’s mails, I reply
> your patch here.
> I have some question for the patch.
> 
> > No. Basic O_DIRECT does not guarantee atomicity of requests, which
> > is
> > why we do not have generic locking at the VFS level when reading
> > and
> > writing. The only guarantee being offered is that O_DIRECT and
> > buffered
> > writes do not collide.
> Do you mean other fs also cant guarantee atomicity of O_DIRECT
> request or just nfs?
> 
> > IOW: I think the basic premise for this test is just broken (as I
> > commented in the patch series I sent) because it is assuming a
> > behaviour that is simply not guaranteed.
> So the generic/465 of xfstests can’t apply to nfs for now, am I
> right?

As far as I can see, it is does not belong in the 'generic' category at
all.

> 
> > BTW: note that buffered writes have the same property. They are
> > ordered
> > when being written into the page cache, meaning that reads on the
> > same
> > client will see no holes, however if you try to read from another
> > client, then you will see the same behaviour, with temporary holes
> > magically appearing in the file.
> As you say, nfs buffered write also has the hole problem with
> multiple r/w on different clients.
> I want to know if the problem exists in other local fs such as
> xfs,ext4?
> 

There is no VFS locking that enforces any serialisation for O_DIRECT.
So unless the filesystem implements its own serialisation (which xfs
does) then there is no guarantee.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com