If you wish to avoid the recovery method, you can still use an external log
with your RAID. If you're using hardware RAID, where the array spans the
entire drive, create two partitions on the array (sda1 and sda2, where sda2
is used for the log and is less than 256MB). If you're using software raid,
then it's just as easy. Just create a couple of partitions on each drive in
the array. You'll then create an md1 stripe across one set of partitions
for data and another stripe (md2) on another set of partitions for metadata.
You can then use the following: mkfs.xfs -l logdev=/dev/sda2,size=32000b
/dev/sda1. You can substitute md1 and md2 accordingly.
It won't matter that you're creating a metadata device and a data device on
the same physical set of drives. You're still creating a new page buffer
for the new logical device and this is where you'll speed up performance.
The performance hit of physical disk seeks should be negligible. I've
actually benchmarked the difference between putting the journal on other
RAID stripes, other raids, fast disks, NVRAM, etc. You really shouldn't
notice much difference. Plus, placing the log on another stripe is pretty
cheap to do.
From: linux-xfs-bounce@xxxxxxxxxxx [mailto:linux-xfs-bounce@xxxxxxxxxxx] On
Behalf Of Eric Sandeen
Sent: Thursday, January 01, 2004 9:33 AM
To: Jerry Haltom
Cc: 'linux-xfs list'
Subject: Re: XFS external log questions
There are a couple of reasons for using an external log.
If there is a dedicated block device for the log, then
log writes won't cause the head to seek away from the data,
which could speed things up. Of course in a raid this is
probably less critical, as the notion of "the head" is a little
Also, log writes are done in sector-sized units, while data
writes are done in filesystem block-sized units. In software
MD raids, this size-switching is very inefficient. Putting
the log on an external device alleviates this (as would setting
the sector size equal to the block size, but I think that codepath
is a bit less tested). I don't think that hardware raid performance
suffers from this size-switching, but I suppose some implementations
might. I'm not well-versed in hardware raids.
The log does not take up much space at all, maximum 65536
filesystem blocks, or 256M on a 4k block filesystem. Defaults
are usually much smaller than this.
If the log device fails, you don't lose the whole filesystem,
but you will lose any metadata in the log. You could recover
by replacing the device, and running xfs_repair -L to zero
out the log device and repairing the fallout from the missing
log. Not ideal, but it should not be catastrophic.
On Thu, 1 Jan 2004, Jerry Haltom wrote:
> Few questions about setting up and using a proper external log:
> I have a system whose only drive is a raid 5 array. I assume putting hte
> log on the array itself, on another partition, would be pretty useless,
> if the data is on the array also. So, I could put in anohter drive, but
> what are the usual redundency requirements for the external log? I
> assume if it fails, the entire partition fails also.
> So, one would need two raid setups to use this effectively? How much
> data does the log usually use?
> Jerry Haltom <jhaltom@xxxxxxxxxxxxxxxxxxx>
> Feedback Plus, Inc.