Precisely, Trond! :-) That's why the cookie verifier turned out to be a untenable idea. The application itself, not just the application level, must participate in the recovery. If the rm command wants to ensure that it removes every entry in a directory before attempting to remove the directory itself, then it must arrange to do so and can't really assume that directory cookies can never become invalid. Perhaps it could on a purely POSIX system, I dunno, but I am not sure that a pure POSIX system exists anywhere. ps -----Original Message----- From: Myklebust, Trond [mailto:Trond.Myklebust@xxxxxxxxxx] Sent: Friday, March 30, 2012 11:47 AM To: Peter Staubach Cc: Matt W. Benjamin; Boaz Harrosh; linux-nfs; Ganesha NFS List Subject: RE: unlink within an open directory stream On Fri, 2012-03-30 at 11:24 -0400, Peter Staubach wrote: > Yes, hmmm, ummm... > > A long time, I thought that the readdir cookie verifier sounded like a good idea. After all, if directories can be compacted, it would be nice to be able to tell when the cookie has become invalid, right? So, I added it to the NFSv3 protocol. > > It was only afterwards, in attempting to implement it, that the real truth was discovered. This is that the interfaces are not sufficient to be able to convey this information sufficiently and to be able to recover from the situation. Currently, recovery require action on the part of the application. > > In retrospect, I wouldn't add the cookie verifier if I was doing it again. > > Thanks for the support, though. :-) > > I do disagree with Trond though, in that applications must be coded to be able to handle directories where cookies can become invalidated. That's why rm and such have to be coded to keep track of their location in the directory by more than just d_off. The problem with that is that there is no standard for how applications should proceed to do this, and so there are no guidelines for how the client should behave. Worse, if you've looked at the glibc readdir library code, you'll have noticed that it _depends_ on being able to use a strictly POSIX-conforming version of telldir()/seekdir(). If it can't rewind to a previously saved offset, then it can end up skipping entries. So no, I can't rely on applications either... > ps > > > -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx > [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Matt W. Benjamin > Sent: Monday, March 26, 2012 2:55 PM > To: Boaz Harrosh > Cc: linux-nfs; Ganesha NFS List; Trond Myklebust > Subject: Re: unlink within an open directory stream > > Hi, > > Boaz: we do not any longer send a readdir index. We do send a cookieverf. > > Fist of all, I haven't established that the issue we're actually observing is caused by the Linux client sending old cookies to readdir(something). However, if it is, it's in no way better to try to make cookies "more persistent." Nor should the Linux client be expecting it. The assumption is simply flawed. The protocol introduced cookie verifier (a LONG time ago) for a reason. > > Matt > ----- "Boaz Harrosh" <bharrosh@xxxxxxxxxxx> wrote: > > > On 03/26/2012 11:25 AM, Myklebust, Trond wrote: > > > > > On Mon, 2012-03-26 at 11:17 -0700, Boaz Harrosh wrote: > > >> On 03/24/2012 10:12 AM, Myklebust, Trond wrote: > > >> > > >> > > >> It's the new (post RHEL 6.0 Kernel) NFS need for opendir after an > > unlink. > > > > > > What? > > > > > > > > > The links below report on regression in RHEL 6.2 which have a new > > NFS implementation where 6.0 used to be fine. > > (Or it's what I understood from the reporters) > > > > <snip> > > > > > > > > > > No. > > > > > > If the server supports permanent readdir cookies, then there is no > > need > > > for opendir after unlink. > > > > > > If the server does not have permanent readdir cookies, then our > > client > > > has never supported it anyway (nor will it ever do so). That whole > > > 'cookieverf' READDIR bullshit has never provided a workable model > > for a > > > POSIX client... > > > > > > Thanks Trond for the explanation. Forgive my slowness. So you are > > saying that with knfsd it's actually filesystem dependent and maybe > > the reporters did not compare apples-to-apples and the difference is > > in the behind file system. > > > > Matt I'm sure Trond is right with regard to Ganesha, because we send > > a readdir index and a cookieverf, which will change after unlink. > > Since the application does not call opendir again the client will > > send the old cookies, which is now a different file or might get > > out-of-bounds for Ganesha. > > > > Let me think about it a bit. I'm sure we can send a Better 64bit > > cookie, which will be more persistent, even across unlinks. > > > > > > > > > > > > > > Thanks > > Boaz > > -- > Matt Benjamin > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > http://linuxbox.com > > tel. 734-761-4689 > fax. 734-769-8938 > cel. 734-216-5309 > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" > in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo > info at http://vger.kernel.org/majordomo-info.html -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
