https://bugzilla.kernel.org/show_bug.cgi?id=16348
--- Comment #15 from Dave Chinner <david@xxxxxxxxxxxxx> 2010-07-13 22:41:09 ---
(In reply to comment #14)
> This vast amount of allocation groups was the result of a lot of performance
> tuning and pecking with a stick in the fog when we started to use xfs. We have
> a _lot_ of small and huge files and ran into 'disk-full / out-of-inodes'.
> anyway, we thought the bottleneck came from not having enough allocationgroups
> spread on the surface. 2048*1668912 equals approx 13*268435392.
Sounds like you were running out of space below 1TB - the inode32 allocator
problem. THis probably would have gone away with the inode64 mount option.
> in the past we supplied agcount=2048 to mkfs.xfs
>
> # mkfs.xfs -b size=4096 -d sunit=128,swidth=1792,agcount=2048 -L x0060
> /dev/sdb
>
> whereas we now initialize the raid6 (14+2) unit more or less per default:
>
> # mkfs.xfs -L x2002 -d su=256k,sw=14 /dev/sdf
>
> Maybe this agcount thing wasn't a good idea, but it worked fine up until the
> xfs-code changed a lot in the past 6 month (2.6.32+ ?!)
Yeah, we've move all the inode caching and reclaim to per-ag structures, and
there are now some places where we iterate over all the AGs to sum counters.
THe inode reclaim shrinker is one of these places and it is clear that it needs
improvement. (well, we knew that already....)
I'll try to have some patches for you to test later today.
>
> cheers and thanks for your work so far,
>
> Peter
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
|