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

[Edward Shishkin <edward.shishkin@gmail.com>]

On 09/26/2014 10:09 PM, Ivan Shapovalov wrote:
> On Friday 26 September 2014 at 21:57:13, Edward Shishkin wrote:	
>> On 09/26/2014 07:27 PM, Ivan Shapovalov wrote:
>>> 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?...)
>>
>> Currently I don't know open issues, which lead to data corruptions.
>>
>> There is a number of failed assertions when debug mode is on and
>> partition is formatted with "create=reg40". Specifically, they appear
>> in paths of tail conversion. I believe they are false positives, however,
>> everything is possible..
>>
>>
>>> So this becomes re-classified as kernel version agnostic bug, right? Then why
>>> do you see it in 3.16 only?..
>>
>> Not really. The issue of non-deletable directories is very old.
>> Now we know that it was caused by non-unique keys (because of
>> hash collisions). However, having non-unique keys on the partition
>> is not enough to reproduce this problem: the cut offset should be
>> between objects with identical keys. Now let's assume that tree
>> layout depends on the kernel version...
>>
>>
>>>> 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? */
>>
>> Discard support v8 looks OK, we'll include it to 3.6.X.
> v8 is what? I don't see any PATCHv8 in the mailing list...


v8 means (v7 + unconditionally delayed de-allocation)


> Actually, by "second space allocation patchset" I've meant this:
> http://www.spinics.net/lists/reiserfs-devel/msg04180.html


Ah, sorry, I forgot about this patchset,
Ok, I'll take a look..

Edward.


>
> BTW, it should be [RFC]: I'm completely unsure if it's OK...
>
>> As to FITRIM ioctl: I'll try to review it at the end of my vacations
>> (weekends 11, 12 Oct).
> OK, will be waiting, thanks.