Re: Non-deleted directories (Was Re: reiser4 (ccreg40)...)

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

 



On Wednesday 24 September 2014 at 21:51:53, Edward Shishkin wrote:	
> On 09/11/2014 07:16 PM, Edward Shishkin wrote:
> >
> > On 09/10/2014 11:39 PM, Ivan Shapovalov wrote:
> >
> 
> [...]
> 
> >>>> 3a. I can reproduce the "directory not empty" bug :) Interestingly, 
> >>>> it is
> >>>> always the same directory under the aforementioned huge hierarchy. 
> >>>> (I've
> >>>> done the unpack-remove cycle a few times.)
> >>> I've made a conclusion that this is caused by unexpected disappearing
> >>> of a record, which represents a directory entry in the directory item
> >>> (currently directory items are managed by cde ITEM plugin, aka 
> >>> "compound
> >>> directory entries"). In the error path (ENOENT) the size of the 
> >>> directory is
> >>> not decremented, which makes the directory undeletable. I still 
> >>> don't know
> >>> who kills the entries. Special debugging info is needed to find/fix it.
> >> What kind of information is needed?
> >
> >
> > We need to find all places, where the records are created / killed
> > and insert a hook, which prints such events for the entry which
> > unexpectedly disappears. This will get us a chance to find the culprit.
> > I have to say: this is not a big fun...
> 
> 
> Ughhh, parse_cut (node40.c) is the culprit.
> If region to cut contains objects with non-unique keys (the case of
> hash collisions), then this function evaluates the cut mode incorrectly.

> non-unique keys

Wow.
(I wonder, how many else "what the..."-style things are there in reiser4?...)

So this becomes re-classified as kernel version agnostic bug, right? Then why
do you see it in 3.16 only?..

> 
> I think that this bug has been introduced implicitly ~11 years ago
> after the design change in reiser4 (introducing non-unique keys).
> 
> I'll provide the fixup later..

Great. Will be waiting for. /* also, what's with batch discard code and the
second space allocation patchset? do you have any plans for reviewing it? */

Thanks,
-- 
Ivan Shapovalov / intelfx /

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux