[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rm -r sometimes produces errors under NFS

From: Jim Meyering
Subject: Re: rm -r sometimes produces errors under NFS
Date: Tue, 06 Mar 2007 09:03:46 +0100

Paul Eggert <address@hidden> wrote:

> Vincent Lefevre <address@hidden> writes:
>> The problem here is the NFS *client*, isn't it? And I'm not sure this
>> is really a bug of the NFS client, knowing the fact that NFS works
>> asynchronously.
> No, you're right, I don't see a bug in the GNU/Linux NFS client here.
> The original workaround has to do with Mac OS X; see
> http://lists.gnu.org/archive/html/bug-coreutils/2006-09/msg00359.html
> http://lists.gnu.org/archive/html/bug-coreutils/2006-09/msg00368.html
> and it's the workaround that is running afoul of the GNU/Linux NFS
> client.  If we could get rid of the workaround somehow, we wouldn't
> have a problem on GNU/Linux NFS.  (But I guess we would have a problem
> on buggy MacOS platforms, either NFS client or NFS server I guess,
> though I don't know the details.)


Would you please try changing this definition
(from src/remove.c) to e.g., 200 or 2000,


and see if it lets you use "rm -r ..." with no errors?

If this turns out to be a general problem, there's always
the possibility of rewriting rm to use a different strategy:
read all entries into malloc'd storage the first time, rather
than reopening after processing each sub-directory.

I hesitate to mention this (since I have so little time, now), but a
couple months ago I implemented a prototype to do that, and from what
I recall, it's twice as efficient on directories with very many entries,
but 10x slower on the degenerate hierarchy: a/a/a/a/a/a/...
There's almost certainly room for some optimization to mitigate that 10x,
but this would be a big and potentially disruptive shift.
I'm in no hurry.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]