From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>,
ReiserFS Development mailing list
<reiserfs-devel@vger.kernel.org>
Subject: Non-deleted directories (Was Re: reiser4 (ccreg40)...)
Date: Wed, 24 Sep 2014 21:51:53 +0200 [thread overview]
Message-ID: <542320D9.8050601@gmail.com> (raw)
In-Reply-To: <5411D8F8.2070603@gmail.com>
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.
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..
Edward.
next prev parent reply other threads:[~2014-09-24 19:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 19:00 reiser4 (ccreg40): very slow mount, poor unlink performance, questions about compression modes Ivan Shapovalov
2014-09-10 20:17 ` Edward Shishkin
2014-09-10 21:26 ` Edward Shishkin
2014-09-10 21:39 ` Ivan Shapovalov
2014-09-11 17:16 ` Edward Shishkin
2014-09-24 19:51 ` Edward Shishkin [this message]
2014-09-26 17:27 ` Non-deleted directories (Was Re: reiser4 (ccreg40)...) Ivan Shapovalov
2014-09-26 19:57 ` Edward Shishkin
2014-09-26 20:09 ` Ivan Shapovalov
2014-09-26 20:46 ` Edward Shishkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542320D9.8050601@gmail.com \
--to=edward.shishkin@gmail.com \
--cc=intelfx100@gmail.com \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).