Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> With 4 AGs this must represent the RAID6 or RAID10 case.

Yes, the original RAID 6 case.

>> Yes, in theory, a good cache controller should be able to sort this
>> out. But at least this particular controller is not able to do so and
>> could use a little help.
>
> Is the cache in write-through or write-back mode?  The latter should
> allow for aggressive reordering.  The former none, or very little.  And
> is all of it dedicated to writes, or is it split?  If split, dedicate it
> all to writes.  Linux is going to cache block reads anyway, so it makes
> little sense to cache them in the controller as well.

The cache is a write-back cache. Yes, it’s split 75% write / 25% read.
Changing to 100% write does not make a difference.

I can imagine that the small read cache might be beneficial for
partial stripe writes, when the stripe contents from the untouched
drives are in cache.

>> Also, a single consumer-grade drive is
>> certainly not helped by this write ordering.
>
> Are you referring to the Mushkin SSD I mentioned?

No, I meant rotational storage. But even SSDs should gain at least a
little from a linear write pattern.

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux