From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: reinoud-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Cc: users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Re: NilFS cleanerd bugreport
Date: Fri, 30 Jan 2009 23:18:53 +0900 (JST) [thread overview]
Message-ID: <20090130.231853.99024523.ryusuke@osrg.net> (raw)
In-Reply-To: <20090128205223.GA416-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
Hi Reinoud,
On Wed, 28 Jan 2009 21:52:23 +0100, Reinoud Zandijk wrote:
> Dear folks, dear Ryusuke,
>
> I've found a bug in the cleanerd/nilfs interaction that might give rise to the
> various problems we've seen recently with the cleanerd. It comes down to the
> wrong counting of the number of dirty segments and the wrong counting of the
> number of checkpoints.
>
> I created this disc using the NiLFS version 2.05 with 2.06 userland (AFAIK)
> with mkfs.nilfs and created a sparse file on it with my sparse file generator
> I created for UDF testing. It dismounted fine giving a nilfs_dump
> `vnd0e-dump-3'. When i remounted it again, the cleanerd started after a while
> and after unmounting it gives `vnd03-dump-3-cleanerd'. A diff shows:
<snip>
> And the su and cp files give:
>
> @@ -30743,34 +31480,34 @@
> Reading file `SU.out` for 1 blocks (4 Kb)
>
> SU file dump
> - nclean 491
> - ndirty 8
> + nclean 496
> + ndirty 21474836483
> last alloced 7
>
> Segment 0
> - Last modified Sun Jan 25 17:05:28 2009
> - Containing nblks 2047
> - Flags 0x2<DIRTY>
> + Last modified Thu Jan 1 01:00:00 1970
> + Containing nblks 0
> + Flags 0x0
>
> ......
>
> @@ -30789,136 +31526,72 @@
>
> Reading file `CP.out` for 1 blocks (4 Kb)
> CP file dump
> - Number of checkpoints 8
> + Number of checkpoints 8589934596
> Number of snapshots 0
>
> Checkpoint number 1
> - Flags 0x0
> + Flags 0x2<INVALID>
> Checkpoints in block 0
> Created at Sun Jan 25 17:05:10 2009
> Blocks incremented 11
> Inodes count 3
> Blocks count (red.) 9
>
> ny idea as to if and why this can happen?
looks underflow or collision of updates.
> Has it been fixed in the meantime?
Not yet, I think.
> or could this be a clue as to the wierd behaviour seen by others including the
> corruption?
I don't know. As I remember, the cleanerd does not depend on these
values, but it may be indirectly-induced.
Anyway, thanks for reporting this issue.
I'll review the cpfile and sufile again.
Regards,
Ryusuke Konishi
next prev parent reply other threads:[~2009-01-30 14:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 20:52 NilFS cleanerd bugreport Reinoud Zandijk
[not found] ` <20090128205223.GA416-5cYspOl2ggRz6xQTk39kMVfVdRo2wo/d@public.gmane.org>
2009-01-30 14:18 ` Ryusuke Konishi [this message]
[not found] ` <20090130.231853.99024523.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-02-02 7:24 ` Ryusuke Konishi
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=20090130.231853.99024523.ryusuke@osrg.net \
--to=ryusuke-sg5x7nla6pw@public.gmane.org \
--cc=reinoud-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
--cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.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