[Top] [All Lists]

Re: raid5: switching cache buffer size

To: XFS Mailing List <linux-xfs@xxxxxxxxxxx>
Subject: Re: raid5: switching cache buffer size
From: Danny Cox <danscox@xxxxxxxxxxxxxx>
Date: 29 Apr 2003 23:38:26 -0400
In-reply-to: <Pine.LNX.4.53.0304291712510.2357@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Organization: No Organization at ALL
References: <Pine.LNX.4.53.0304291712510.2357@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx

On Tue, 2003-04-29 at 18:24, Daryl Herzmann wrote:
> Apr 29 17:15:48 zzz kernel: raid5: switching cache buffer size, 4096 
> --> 512
> Apr 29 17:15:48 zzz kernel: raid5: switching cache buffer size, 512 
> --> 4096

        This happens when using the version 1 log.  Steve worked this out
awhile back, introducing version 2 logging.  This helps a great deal.

        The technical overview is this: XFS writes FS data in 4096 byte blocks,
but the log is written in 512 byte blocks (at least for version 1).  The
design of the RAID 5 driver means that while it's humming along dealing
with 4K blocks and gets a request to handle a 512 byte block, it must
flush it's stripe cache of the 4K buffers, and allocate them for 512
byte buffers, and then switch back again.  It's harmless, in that the
data is still safe, but it's much slower.

        To convert your version 1 log to version 2, the safest way would be to
copy it all out, re-create the fs with mkfs.xfs, and copy the data back
in.  There's another way to do it in place, and you can find the exact
incantation in the archives, but it's not recommended.

        Perhaps Steve will explain the version 2 logging and why it's faster.

        As to why you're just seeing this now, I haven't a clue :-(.

kernel, n.: A part of an operating system that preserves the
medieval traditions of sorcery and black art.


<Prev in Thread] Current Thread [Next in Thread>