FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 02-25-2009, 08:11 PM
Theodore Tso
 
Default Questions regarding journal replay

On Wed, Feb 25, 2009 at 08:02:15PM +0100, Ralf Hildebrandt wrote:
> >
> > Did you find some documentation that actually recommend that large of
> > an external journal?
>
> It says the "journal has a maximum size of 128M"

That's clearly not right. Where did you see that? We should make
sure it gets fixed...

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 02-25-2009, 08:15 PM
Theodore Tso
 
Default Questions regarding journal replay

On Wed, Feb 25, 2009 at 08:01:31PM +0100, Ralf Hildebrandt wrote:
> * Theodore Tso <tytso@mit.edu>:
>
> > Increasing the journal size may speed up certain filesystem workloads
> > which are causing the journal to wrap very frequently. However,
> > increasing the journal *will* increase the time to replay the journal....
>
> Indeed. This is a Maildir-style mailbox server. Many small writes,
> reads and deletes.
>
> > How long did the journal replay take when you were using the 128MB
> > internal inode?
>
> 800s

So maybe I missed it, but about how long did it take with your 32GB
external journal?

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 02-25-2009, 08:47 PM
Ralf Hildebrandt
 
Default Questions regarding journal replay

* Theodore Tso <tytso@mit.edu>:
> On Wed, Feb 25, 2009 at 08:01:31PM +0100, Ralf Hildebrandt wrote:
> > * Theodore Tso <tytso@mit.edu>:
> >
> > > Increasing the journal size may speed up certain filesystem workloads
> > > which are causing the journal to wrap very frequently. However,
> > > increasing the journal *will* increase the time to replay the journal....
> >
> > Indeed. This is a Maildir-style mailbox server. Many small writes,
> > reads and deletes.
> >
> > > How long did the journal replay take when you were using the 128MB
> > > internal inode?
> >
> > 800s
>
> So maybe I missed it, but about how long did it take with your 32GB
> external journal?

One hour


--
Ralf Hildebrandt Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
Geschäftsbereich IT | Abt. Netzwerk Fax. +49 (0)30-450 570-962
Hindenburgdamm 30 | 12200 Berlin

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 02-27-2009, 03:40 PM
Ralf Hildebrandt
 
Default Questions regarding journal replay

* Theodore Tso <tytso@mit.edu>:
> On Wed, Feb 25, 2009 at 08:02:15PM +0100, Ralf Hildebrandt wrote:
> > >
> > > Did you find some documentation that actually recommend that large of
> > > an external journal?
> >
> > It says the "journal has a maximum size of 128M"
>
> That's clearly not right. Where did you see that? We should make
> sure it gets fixed...

The journal options in the tune2fs man page say:

****** CITE *********

size=journal-size

Create a journal stored in the filesystem of size journal-size megabytes.
The size of the journal must be at least 1024 filesystem blocks (i.e.,
1MB if using 1k blocks, 4MB if using 4k blocks, etc.) and may be no more
than 102,400 filesystem blocks. There must be enough free space in the
filesystem to create a journal of that size.

device=external-journal

Attach the filesystem to the journal block device located on
external-journal. The external journal must have been already created
using the command

mke2fs -O journal_dev external-journal

Note that external-journal must be formatted with the same block size as
filesystems which will be using it. In addition, while there is support
for attaching multiple filesystems to a single external journal, the
Linux kernel and e2fsck(8) do not currently support shared exter‐ nal
journals yet.

****** CITE *********

It would be nice if the manpage included a sentence like:

If an external journal is used, the whole journal block device will be
used as journal.

The sentence "... be no more than 102,400 filesystem blocks." gives the
impression (to me, that is) that the same restrcition applies to an
external-journal as well!

Yes, I know *NOW* that's not the case.

--
Ralf Hildebrandt Ralf.Hildebrandt@charite.de
Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
Geschäftsbereich IT | Abt. Netzwerk Fax. +49 (0)30-450 570-962
Hindenburgdamm 30 | 12200 Berlin

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 03-03-2009, 02:27 PM
Eric Sandeen
 
Default Questions regarding journal replay

Ralf Hildebrandt wrote:
> * Eric Sandeen <sandeen@redhat.com>:
>
>>> Journal block size: 4096
>>> Journal length: 8488436
>>> Journal first block: 2
>>> Journal sequence: 0x0027c611
>>> Journal start: 2
>>> Journal number of users: 1
>>> Journal users: 032613d3-6035-4872-bc0a-11db92feec5e
>> Ok we might be getting a little off-track here. Your journal is indeed
>> 32G in size. But you also saw this with an internal journal, which
>> should be limited to 128M, and yet you still saw a very long replay, right?
>
> 800s for 128M, yes

So how well can you reproduce this... it would be interesting to run
this recovery under blktrace, to see where the IO is happening.

I'd be most interested in that for the "normal" 128M log, not the crazy
32G log

-Eric

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 

Thread Tools




All times are GMT. The time now is 09:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org