xfs
[Top] [All Lists]

Re: Performance question

To: Joshua Baker-LePain <jlb17@xxxxxxxx>
Subject: Re: Performance question
From: Seth Mos <knuffie@xxxxxxxxx>
Date: Wed, 18 Feb 2004 20:43:12 +0100
Cc: Linux xfs mailing list <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.58.0402181422130.25541@chaos.egr.duke.edu>
References: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl>
Sender: linux-xfs-bounce@xxxxxxxxxxx
At 14:25 18-2-2004 -0500, Joshua Baker-LePain wrote:
On Wed, 18 Feb 2004 at 7:41pm, Seth Mos wrote

> At 12:57 18-2-2004 -0500, Joshua Baker-LePain wrote:

> You could flip the cover and see if the disks are pushed hard by the
> controller (leds on the 3ware controller). Although from what you described
> above it's probably a directory growing a bit on the large side.
Yeah, I really think it's the large number of files. I'm working to see
how much of them we can clean up right now. I was wondering if xfs_fsr
would be a good idea, but ISTR it not being all that highly recommended.

You might be able to make 1 2 3 4 5 ... directories or based on the first letter. the is also very often at providers with a _lot_ of usernames.


This will greatly reduce the amount of files in one directory and thus make doing dumps a lot easier and faster. XFS was was ment to be scalable but 413 million files (if I read correctly) is stretching it.

> Perhaps creating the filessystem with a larger inode size like 512. You
> could also use version logs instead of version which mostly helped software
> raid 5 although this might help hardware as well.


Again, mkfs is a hard sell right now.

My brain is failing right now, but I think you might be able to xfs_growfs. Search the archive for it.


Cheers

--
Seth
I don't make sense, I don't pretend to either. Questions?


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