weirdness in reiserfs

weirdness in reiserfs

[Matt Bernstein]

I have a 240GB reiserfs ataraid partition on one of my servers (2.4.9-ac10
+ ext3 0.9.9 + ext3 speedup + ext3 "experimental VM patch" + jfs 1.0.4),
which I had populated with lots of little files, probably huge amounts of
tail-packing going on.

I deleted a tarball of one of my directories; I forget how big the file
was, but I reckon it was of the order of 25GB. It took long enough (over
an hour) that I went to the pub with fingers crossed instead of nursing
it. While it was deleting vmstat 1 was showing bi= ~ 2000 and bo= ~ 20000,
so it was hammering away. Fine, I thought, it's a big file; I don't do
this sort of thing often, maybe the stuff needed to delete such a big file
is bigger than the journal size or something. But.. the partition was
otherwise inaccessible with processes just blocking. Oddly df worked
though, so I could watch my use of the filesystem going down!

So.. I came back in this morning and things had recovered. Weird. Could
the "experimental VM patch" mentioned on the ext3 for 2.4 page be a little
too experimental? Sorry to be so vague...

Matt

Re: weirdness in reiserfs

[Nikita Danilov]

Matt Bernstein writes:
 > I have a 240GB reiserfs ataraid partition on one of my servers (2.4.9-ac10
 > + ext3 0.9.9 + ext3 speedup + ext3 "experimental VM patch" + jfs 1.0.4),
 > which I had populated with lots of little files, probably huge amounts of
 > tail-packing going on.
 > 
 > I deleted a tarball of one of my directories; I forget how big the file
 > was, but I reckon it was of the order of 25GB. It took long enough (over
 > an hour) that I went to the pub with fingers crossed instead of nursing
 > it. While it was deleting vmstat 1 was showing bi= ~ 2000 and bo= ~ 20000,
 > so it was hammering away. Fine, I thought, it's a big file; I don't do
 > this sort of thing often, maybe the stuff needed to delete such a big file
 > is bigger than the journal size or something. But.. the partition was
 > otherwise inaccessible with processes just blocking. Oddly df worked
 > though, so I could watch my use of the filesystem going down!

Were there reiserfs-related messages in the kernel log?

 > 
 > So.. I came back in this morning and things had recovered. Weird. Could
 > the "experimental VM patch" mentioned on the ext3 for 2.4 page be a little
 > too experimental? Sorry to be so vague...
 > 
 > Matt

Nikita.

 > 
 > -
 > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
 > Please read the FAQ at  http://www.tux.org/lkml/

Re: weirdness in reiserfs

[Matt Bernstein]

At 18:55 +0400 Nikita Danilov wrote:

> > I have a 240GB reiserfs ataraid partition on one of my servers (2.4.9-ac10
[snip]
> > I deleted a tarball of one of my directories; I forget how big the file
[snip]
> > is bigger than the journal size or something. But.. the partition was
> > otherwise inaccessible with processes just blocking. Oddly df worked
> > though, so I could watch my use of the filesystem going down!
>
>Were there reiserfs-related messages in the kernel log?

No.. nothing to go on :-/

Re: weirdness in reiserfs

[Chris Mason]

On Friday, September 28, 2001 03:44:19 PM +0100 Matt Bernstein
<matt@theBachChoir.org.uk> wrote:

> I have a 240GB reiserfs ataraid partition on one of my servers (2.4.9-ac10
> + ext3 0.9.9 + ext3 speedup + ext3 "experimental VM patch" + jfs 1.0.4),
> which I had populated with lots of little files, probably huge amounts of
> tail-packing going on.

[ slow deleting of 25GB, horrible latency ]

Hmmm, I'd be curious to see how 2.4.9-ac16 (or 2.4.10) performs there.  The
reiserfs delete code should be scheduling enough due to transaction
stop/starts that interactive performance isn't that bad.

You should be able to repeat your results by doing the same tests on sparse
files:

dd if=/dev/zero of=foo bs=1M count=1 seek=250000

-chris

Re: weirdness in reiserfs

[Matt Bernstein]

At 11:02 -0400 Chris Mason wrote:

[ 2.4.9-ac10ish.. slow deleting of 25GB, horrible latency ]
>
>Hmmm, I'd be curious to see how 2.4.9-ac16 (or 2.4.10) performs there.  The
>reiserfs delete code should be scheduling enough due to transaction
>stop/starts that interactive performance isn't that bad.

Will check both of you suggestions over the next few days, thanks!

>You should be able to repeat your results by doing the same tests on sparse
>files:
>
>dd if=/dev/zero of=foo bs=1M count=1 seek=250000