> On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
> >
Valdis.Kletnieks@vt.edu wrote:
> >> It will become even *more* of a "not that common"
> if the lock will
> >> block moves and ACL changes *across the
> filesystem* for
> >> potentially *minutes* at a time.
> >
> > It will not take anywhere NEAR minutes at a time
> to update the in
> > memory dentries, more like 50ms.
>
> One last comment:
>
> 50ms to update in-memory dentries would be FRIGGING
> TERRIBLE!!!
> Using Perl, an interpreted language, the following
> script takes 3.39s
> to run on one of my lower-end systems:
>
> for (0 .. 10000) {
> mkdir "a-$_";
> mkdir "b-$_";
> rename "a-$_", "b-$_";
> }
>
> It's not even deleting things afterwards so it's
> populating a
> directory with ten thousand entries. We can easily
> calculate
> 10,000/3.39 = 2,949 entries per second, or 0.339
> milliseconds per entry.
>
> When I change it to rmdir things instead, the
> runtime goes down to
> 2.89s == 3460 entries/sec == 0.289 milliseconds per
> entry.
>
> If such a scheme even increases the overhead of a
> directory rename by
> a hundredth of a millisecond on that box it would
> easily be a 2-3%
> performance hit. Given that people tend to kill for
> 1% performance
> boosts, that's not likely to be a good idea.
>
> Cheers,
> Kyle Moffett
>
>
