xfs
[Top] [All Lists]

Re: Failure growing xfs with linux 3.10.5

To: stan@xxxxxxxxxxxxxxxxx
Subject: Re: Failure growing xfs with linux 3.10.5
From: Michael Maier <m1278468@xxxxxxxxxxx>
Date: Wed, 14 Aug 2013 20:13:05 +0200
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <520BBEFB.9030002@xxxxxxxxxxxxxxxxx>
References: <52073905.8010608@xxxxxxxxxxx> <5207D9C4.7020102@xxxxxxxxxxx> <52090C6C.6060604@xxxxxxxxxxx> <20130813000453.GQ12779@dastard> <520A5132.6090608@xxxxxxxxxxx> <520B1B4F.9070800@xxxxxxxxxxxxxxxxx> <520B9CCF.1040908@xxxxxxxxxxx> <520BBEFB.9030002@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20
Stan Hoeppner wrote:
> If you keep growing until you consume the disk, you'll have ~100
> allocation groups.  Typically you'd want to have no more than 4 AGs per
> spindle.  You already have 42 (or 45) which will tend to seek the disk
> to death with many workloads, driving latency through the roof and
> decreasing throughput substantially.  Do you notice any performance
> problems yet?

What are expected rates for copying e.g. a 10GB file? It's a Seagate
Barracuda 3000GB Model ST3000DM001 SATA connected to SATA 6 Gb/s chip.
The source and the destination FS is LUKS crypted. About 3 GB usable RAM
(cache), AMD FX-8350 processor @ max. 3800MHz.

It's getting slower as more as the free space on the fs is reduced
(beginning at about the last GB). Resizing it makes the problem
disappear again.

> Or is this XFS strictly being used as a WORM like backup
> silo?

yes


Thanks,
Michael

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