RE: [Ext2-devel] bug in ext3 htree rename: doesn't delete old nam

[Christopher Li]

-----Original Message-----
From: Jeremy Fitzhardinge
To: [e-mail]
Cc: Ext2 devel; Linux Kernel List
Sent: 11/5/02 9:02 PM
Subject: Re: [Ext2-devel] bug in ext3 htree rename: doesn't delete old name,
leaves ino with bad nlink

On Tue, 2002-11-05 at 13:24, [e-mail] wrote:

>Thanks for looking at it so quickly.  I want ext3+htree to stabilise as
>quickly as possible, and since I had a nice reproducible bug, I may as
>well make the most of it.

That save me a lot of time to duplicate the bug. I want to make htree
stablilise quickly also.

>Yes, I would have guessed that it was related to a tree split.  The
>interesting thing to me is that it happened twice in this particular
>run, and yet it must be a fairly uncommon occurrence overall (otherwise
>it would have been reported before).  I wonder if it really is a rare
>event, or it has just gone unnoticed?

It is a relative rare event. Let's see. To make this happen, rename need to
add new entry and split the dir entry block. Depend on how much space left
on
your leaf block. Let's say your average filename length is 9. A dir entry
record is 24 bytes. A 4K block can have 170 entries. Given htree after split
is half full. Chance to hit a split on add an entry is about 1/85.
Assuem you have N leaf dir entry blocks in your dir. Chance of the old file
entry in the same block of new file entry is 1/N. Chance of old file
not in the same block after split is 1/2.

So total chance is about 1/(170*N). When you have relative small
direcotrys, the chance is bigger than huge directorys.

>Update it in what way?  In principle a rename is an atomic operation, so
>other things shouldn't be able to observe the directory in an
>intermediate state.

I mean when split dir entry blocks, it will move the dir entry inside
that block. I am not clear about do we need to invalidate the dentry
cache for those changed entry. I need to check the source.

Cheers

Chris

	J