RE: [PATCH] htree nfs fix

RE: [PATCH] htree nfs fix

[Trond Myklebust]

Get the facts right please: That rant was bullshit.

  NFS tries as hard as it can to interpret the cookie as a bag of
bits. It gets screwed in this by a VFS interface which treats the
32-bit getdents() as having unsigned 32-bit cookies, and the 64-bit
getdents64() as having signed 64-bit cookies.

To make matters worse, glibc comes along and assumes it can use
getdents64 as a substitute for getdents() without having to give any
thought to the problem of cookies.


If you're unhappy with the state of readdir, then fix the VFS/glibc.
At the moment it is simply not possible to write a consistent readdir
at the NFS level.

Trond

Re: [PATCH] htree nfs fix

[Andrew Morton]

Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> If you're unhappy with the state of readdir, then fix the VFS/glibc.

What should be done?

Re: [PATCH] htree nfs fix

[Trond Myklebust]

>>>>> " " == Andrew Morton <akpm@digeo.com> writes:

     > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
    >>
    >> If you're unhappy with the state of readdir, then fix the
    >> VFS/glibc.

     > What should be done?

Either we have to agree that we break legacy 32-bit getdents() and
treat all cookies as signed 32/64-bit, or we break getdents64(), and
treat all cookies as unsigned. (This applies to both 2.5.x and 2.4.x)

The former will (IIRC) break setups with those IRIX servers that like
to use 0xFFFFFFFF as an end-of-readdir marker. It also requires an
extra patch in order to mangle the otherwise unsigned NFS
cookies. (This patch has been ready but withheld from the official
kernel tree pending a decision on this issue for at least 2 years -
hence my irritation whenever this subject comes up)

The latter will break glibc, which likes to abuse getdents64() and
simply test for signed 32-bit overflow in place of using the 32-bit
getdents().

Cheers,
  Trond

Re: [PATCH] htree nfs fix

[Andrew Morton]

Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> >>>>> " " == Andrew Morton <akpm@digeo.com> writes:
> 
>      > Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>     >>
>     >> If you're unhappy with the state of readdir, then fix the
>     >> VFS/glibc.
> 
>      > What should be done?
> 
> Either we have to agree that we break legacy 32-bit getdents() and
> treat all cookies as signed 32/64-bit, or we break getdents64(), and
> treat all cookies as unsigned. (This applies to both 2.5.x and 2.4.x)
> 

Or we do nothing.

What would you recommend?

Re: [PATCH] htree nfs fix

[Trond Myklebust]

>>>>> " " == Andrew Morton <akpm@digeo.com> writes:

    >> Either we have to agree that we break legacy 32-bit getdents()
    >> and treat all cookies as signed 32/64-bit, or we break
    >> getdents64(), and treat all cookies as unsigned. (This applies
    >> to both 2.5.x and 2.4.x)
    >>

     > Or we do nothing.

     > What would you recommend?

I frankly don't care. I consider the current situation to be a direct
result of glibc's abuse of getdents64() starting in glibc-2.2. If they
had used 32-bit interfaces for the 32-bit readdir() they way they did
in glibc-2.1 then there would be no 'NFS problem' for people to bitch
about.

Cheers,
  Trond