On Wed, Oct 27, 2010 at 12:27:26AM +0200, Michael Monnerie wrote:
> On Montag, 25. Oktober 2010 Geoffrey Wehrman wrote:
> > I haven't found any documentation to support this, but I have been
> > told that the middle was selected for the single disk case to
> > minimize seek times. The distance the head must travel to or from
> > other locations on the disk is optimized by placing the log in the
> > middle of the disk.
> This is based on the assumption that
> 1) a disk is totally filled with data and
> 2) the partition that XFS resides on is the only one on the disk.
> For PCs or small servers you normally have a swap partition, the
> recommended size is RAMx2 (at least it was once suggested, I've always
> only set it to RAM size). Then you have at least a root filesystem,
> which often won't be XFS, and then the data partition, which could be a
> single partition until the end of the disk. For a single 300GB disk,
> this means that around 20-50GB will be used by "other" (swap, root,
> windows?) partitions, then maybe a single 250-280GB partition for XFS.
Doesn't matter - the placement of the log matters when the XFS
partition is busy, not when you are swapping or your root filesystem
is doing stuff. If you have traffic to multiple partitions at once,
then nothing you do to the filesystem layout will make much
> If you place the journal in the middle of the partition, you are already
> in an area where disks are slower than on the outside. And if you fill
> only half of the partition, it means your log is totally on the end of
> the disk, access-wise.
Well, no. XFS does not fill the filesystem from the start to the
end. XFS spreads the data and metadata across all the allocation
groups, and so there is generally as much metađata/data on either
side of the log at any given time. For example, a kernel tree on a
120GB filesystem with 4 AGs has the following distribution of
So you can see that with the log at the start of AG 2, there is a
pretty even chance of any specific IO in that kernel tree being
either side of the log....
The difference in sequential performance from AG 0 to AG 3 on this
drive is about 10MB/s, but the worst case seek time is around 18ms
and average is about 9ms. IOWs, the benefit of seek time reduction
by placing the log in the middle is for more than the improvement
in sequential throughput would give by placing the log in AG 0.