xfs
[Top] [All Lists]

howto keep xfs directory searches fast for a long time

To: xfs-oss <xfs@xxxxxxxxxxx>
Subject: howto keep xfs directory searches fast for a long time
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 12 Aug 2012 11:14:22 +0200
Organization: it-management http://it-management.at
User-agent: KMail/4.7.2 (Linux/3.5.0-zmi; KDE/4.7.2; x86_64; ; )
I need a VMware VM that has 8TB storage. As I can at max create a 2TB
disk, I need to add 4 disks, and use lvm to concat these. All is on top
of a RAID5 or RAID6 store.

The workload will be storage of mostly large media files (5TB mkv Video
+ 1TB mp3), plus backup of normal documents (1TB .odt,.doc,.pdf etc).
The server should be able to find files quickly, transfer speed is not
important. There won't be many deletes to media files, mostly uploads
and searching for files. Only when it grows full, old files will be
removed. But normal documents will be rsynced (used as backup
destination) regularly.
I will set vm.vfs_cache_pressure = 10, this helps at least keeping
inodes cached when they were read once.

- What is the best setup to get high speed on directory searches? Find,
ls, du, etc. should be quick.
- Should I use inode64 or not?
- If that's an 8 disk RAID-6, should I mkfs.xfs with 6*4 AGs? Or what
would be a good start, or wouldn't it matter at all?

And as it'll be mostly big media files, should I use sunit/swidth set to
64KB/6*64KB, does that make sense?

I'm asking because I had such a VM setup once, and while it was fairly
quick in the beginning, over time it felt much slower on traversing
directories, very seek bound. That xfs was only 80% filled, so shouldn't
have had a fragmentation problem. And I know nothing to fix that apart
from backup/restore, so maybe there's something to prevent that?

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

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

Attachment: signature.asc
Description: This is a digitally signed message part.

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