From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: nfsd changes for 3.5 Date: Thu, 31 May 2012 16:01:38 -0400 Message-ID: <20120531200138.GD25955@fieldses.org> References: <20120531182457.GB25955@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Al Viro To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Thu, May 31, 2012 at 11:58:34AM -0700, Linus Torvalds wrote: > On Thu, May 31, 2012 at 11:24 AM, J. Bruce Fields wrote: > > > > Sorry this is a bit late. =C2=A0In fact I still have a review backl= og (at a > > minimum some bugfixes), so will send a second pull later. >=20 > Quite frankly, I'm not going to pull this without lots of explanation= s. >=20 > The VFS-level changes have no acks or sign-offs from anybody else, Sorry, yes, at best I had a verbal OK from Al (and maybe I'm wrong abou= t that). I got impatient. > and quite frankly, if I understand them correctly they look f*cking > disgusting. If I read them right, they break delegations of a file > (which can involve long waits for clients - no?) Right. By default it's 90 seconds before we'll give up on the client. > while holding on to > the directory inode lock (both directories for cross-inode renames). > Which seems to be a singularly idiotic thing to do and sounds to me > like a fundamental design mistake. I hate that too, and originally tried to avoid it with something like: retry: acquire locks lookup inode ret =3D try_to_break_deleg(inode); if (ret) drop locks really_break_deleg(inode); goto retry; ... do the real work ... drop locks I felt like I was making already complicated code logic like rename's even harder to follow. And those operations don't really know the inode till they acquire the locks, so in pathological cases that could continue forever. =2E.. > So quite frankly, this *all* looks like 3.6 material to me, and that'= s > assuming you can convince people that file-delegation breaking really > should happen with all lookups on the directory the file is in blocke= d > by the directory inode mutex in the first place. Or tell me I'm a > moron and I misread the patches and don't know what I'm talking about= =2E No, I think you understand correctly. The presence of a delegation requires blocking certain operations until a client somewhere responds (or we time out). So the question as I understand it is whether there's a way to lessen the impact by blocking only what we really need to. I don't know if there's a way to do that without reworking the vfs directory locking to be much more fine-grained. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html