lkml.org 
[lkml]   [2002]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [datapoint] Re: 2.5.7 rm -r in tmpfs problem
On Sat, 23 Mar 2002, Alexander Viro wrote:

> There are known problems with rm(1) on ramfs/tmpfs/etc. - the thing assumes
> that offsets in directory remain stable after unlink(2), but locking changes
> didn't affect.

Ok, I finally found a wee bit of clue. I understand the assumption,
and in virgin 2.5.4, that assumption is enforced... somefsckingwhere ;-)

However, the locking changes do affect it in some magical way, and do
cause (well, trigger anyway) the breakage.

In 2.5.4, I creats a directory with 170 (two more than will fit in one call)
entries, and rm -r it. Over all three dcache_readdir() calls, (one for the
first 168 entries (+.+..), one for the last two entries + seek, and one to
determine that we're empty), the dentry count remains stable at 170. If I
apply the locking changes, POOF, my dentries disappear exactly as they do in
kernels >= 2.5.5-pre1.

64 Kibble-$$ question:

Why are my dentries going awol with the locking changes applied?

2.5.4.virgin
enter pos=0 count=170
seek pos=0 count=170
exit pos=170 count=170
enter pos=170 count=170
seek pos=0 count=170
exit pos=172 count=170
enter pos=172 count=170
exit EOF

2.5.4.locking
enter pos=0 count=170
seek pos=0 count=170
exit pos=170 count=170
enter pos=170 count=2
exit EOF

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.091 / U:2.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site