reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).