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.
As to FITRIM ioctl: I'll try to review it at the end of my vacations
(weekends 11, 12 Oct).
Thanks,
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
