xfs
[Top] [All Lists]

Re: Fragmentation of Journaling FS

To: Steve Lord <lord@xxxxxxx>
Subject: Re: Fragmentation of Journaling FS
From: Constantin Loizides <Constantin.Loizides@xxxxxx>
Date: Wed, 01 Aug 2001 16:22:31 +0200
Cc: xfs-list <linux-xfs@xxxxxxxxxxx>
Organization: Innovative Software AG
References: <3B67D35E.64877CBF@isg.de>
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi Steve,

thanks for the comment, I quote it as you sent it directly to me:
> 
> Interesting project, you should note however that your filesystem sizes
> are VERY small in XFS terms, scalable for XFS is refering to scalable
> upwards. You might also want to think about having filesystems which are
> many times your memory size - at 512M you are only 4 times the memory size,
> so a good percentage of the filesystem will be cachable.

Yes, that might be a problem, but it was a quick way to test the setup
of the kernel patches (all went into 2.4.5) 


> 
> XFS divides the disk space into allocation groups, these are independent
> chunks of space management. The mkfs output will show you how many you have,
> the mkfs.xfs man page will tell you how to experiment with them. You default
> to having 8 on a device this small, the allocation groups can be up to
> 4Gbytes each. The drop off in XFS performance at the full filesystem end
> of things is probably caused by having to scan multiple allocation groups
> looking for space - there is an in memory summary, but allocations are
> probably getting scattered around several allocation groups at this point.
> 
> You may find that the performance drop off is caused by seek activity
> in order to get to the log, on ext2 pretty much all seek activity will
> be outside the user's context and happen in the background. With XFS
> at least you can put the log on a separate device and see what happens
> to the numbers.
> 
Ok, that would be easy to check and redo the gauge runs on a system
where the log is on a different device.


Constantin


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