Re: XFS on top RAID10 with odd drives count and 2 near copies

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

On 2/14/2012 5:38 AM, keld@xxxxxxxxxx wrote:
> On Mon, Feb 13, 2012 at 09:49:06PM -0600, Stan Hoeppner wrote:
>> On 2/13/2012 5:02 PM, keld@xxxxxxxxxx wrote:
>>> And anyway, I think a 7 spindle raid10,f2 would be much faster than 
>>> a md linear array setup, both for small files and for largish
>>> sequential files. But try it out and report to us what you find.
>> The results of the target workload should be interesting, given the
>> apparent 7 spindles of stripe width of mdraid10,f2, and only 3 effective
>> spindles with the linear array of mirror pairs, an apparent 4 spindle
>> deficit.
>>> I would expect  a linear md, and also most other MD raids would tend to perform better in 
>>> the almost empty state, as the files will be placed on the faster parts of the spindles.
>> This is not the case with XFS.
>>> raid10,f2 would have a more uniform performance as it gets filled, because read access to 
>>> files would still be to the faster parts of the spindles.
>> This may be the case with EXTx, Reiser, etc, but not with XFS.
>> XFS creates its allocation groups uniformly across the storage device.
>> So assuming your filesystem contains more than a handful of directories,
>> even a very young XFS will have directories and files stored from outer
>> to inner tracks.
> Would not even XFS allocate lower AGs (on faster tracks) first?
>> This layout of AGs, and the way XFS makes use of them, is directly
>> responsible for much of XFS' high performance.  For example, a single
>> file create operation on a full EXTx filesystem will exhibit a ~30ms
>> combined seek delay with an average 3.5" SATA disk.  With XFS it will be
>> ~10ms.  This is because with EXTx the directories are at the outer edge
>> and the free space is on the far inner edge.  With XFS the directory and
>> free space area few tracks apart within the same allocation group.  Once
>> you seek the directory in the AG, the seek latency from there to the
>> track with the free space may be less than 1ms.  The seek distance
>> principal here is the same for single disks and RAID.
> Well, I was talking for a given FS, including XFS. As raid10,f2 limits the read access to the
> faster halves of the spindles, reads will never go to the slower halves. 
> On other raid types than raid10,far with regular use, AGs in use and  data will be spread
> randomly over the disks, including the slower inner tracks. Here raid10,far will only
> use the outer tracks for reading, with some speed-up as a consequence.

Maybe I simply don't understand this 'magic' of the f2 and far layouts.
 If you only read the "faster half" of a spindle, does this mean writes
go to the slower half?  If that's the case, how can you read data that's
never been written?

To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[ATA RAID]     [Linux SCSI Target Infrastructure]     [Managing RAID on Linux]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device-Mapper]     [Kernel]     [Linux Books]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Photos]     [Yosemite Photos]     [Yosemite News]     [AMD 64]     [Linux Networking]

Add to Google Powered by Linux