lkml.org 
[lkml]   [2011]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC] st_nlink after rmdir() and rename()
On Thu, Mar 3, 2011 at 12:46 PM, OGAWA Hirofumi
<hirofumi@mail.parknet.co.jp> wrote:
>
> But, some commands see i_nlink (IIRC, it's checking i_nlink == 2, to
> know empty dir or not).

Actually, that would be a serious bug in the application.

The traditional rule of thumb is that a directory with i_nlink==1 has
a "I'm not counting at all".

For example, I think that's the rule that 'find' uses to decide if a
directory can have subdirectories (and when it could try to stop
scanning early): i_nlink == 1 means that yes, it _can_ have
subdirectories, we just don't know how many.

So checking i_nlink==2 is actually a user-level bug.

> So we have to simulate some levels. I guess you
> are not saying we don't need to care it at all though.

I'm saying that it should just work to set i_nlink=1 and not do
anything at all. Ever. It's a valid model for directory counts.

Seriously - that's what isofs does, for example. It does mean that
'find' for certain cases gets bit more expensive, but on the other
hand, other operations are a lot _less_ expensive.

We might well try that as a FAT mount option, to let people decide
whether they really do want the "scan directories all the time" or
only the "let 'find' scan directories when it needs to" behavior.

Linus


\
 
 \ /
  Last update: 2011-03-03 22:05    [from the cache]
©2003-2011 Jasper Spaans