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
blurry.
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.
-Eric
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?
>
> Thanks
>
> --
> Jerry Haltom <jhaltom@xxxxxxxxxxxxxxxxxxx>
> Feedback Plus, Inc.
>
|