XFS journaling position

[Michael Monnerie]

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. 
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.

So for the average single-disk setup, wouldn't a log at 25%-35% of the 
partition size be quicker than in the middle of the partition? Dave 
Chinner just recently said that "a partition which is 85% filled is 
full, from a filesystem view". That would already mean the log at 42% of 
the partition size would be better. (Greetings to Douglas Adams, again 
he was right ;-)

Just my 2¢, but I don't have a single disk machine with performance 
needs.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Radiointerview zum Thema Spam ******
http://www.it-podcast.at/archiv.html#podcast-100716

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20101027/69d4a6c7/attachment.sig>