Re: Software RAID checksum performance on 24 disks not even close to kernel reported

[Stan Hoeppner <stan@hardwarefreak.com>]

On 6/7/2012 12:22 AM, Igor M Podlesny wrote:
> On 7 June 2012 12:59, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>> On 6/6/2012 10:41 PM, Igor M Podlesny wrote:
>>>    They try, for sure, but try is still a try. For e. g., you pvmove'd
>>> your LVM with XFS from one RAID to another one having different
>>> "layout", things can just stop working well all of the sudden.
>>
>> Filesystems that have zero awareness of the storage geometry have poor
>> performance on striped RAID devices.  XFS has excellent performance on
>> striped RAID specifically due to this awareness.  Now you describe this
> 
>    And Btrfs is way faster (~ 30 %) on single sustained 22 GiB reading
> — http://poige.livejournal.com/560643.html

I don't see anything there that credibly demonstrates what you state
here.  Also note this is an English only mailing list.  Linking to a
forum that is primarily in Russian, I assume, and where half the posts
are by you, doesn't lend any credibility to your arguments.

>    XFS is excellent but for parallel I/O mainly due to its multiple
> allocation groups, not "RAID awareness" 

With storage geometries more complex than a single RAID array, which is
probably more common with XFS than not, allocation groups are then
designed around the storage geometry.  Thus these two things are equally
important to the overall performance of the filesystem, especially with
high IOPS metadata heavy workloads.  So yes, storage geometry awareness
plays a very large role in overall performance.  I don't have the time
to post an example scenario at the moment.  You can see examples in
previous posts of mine relating to maildir performance.

> — EXT3/4 can be formatted
> adjusted to RAID's layout just as XFS, in case you didn't know it.

Yes, EXT can be informed of the geometry on the command line.  I freely
admit I don't keep up with EXT development, but last I recall mke2fs
didn't query md and populate its stripe parameters automatically.  XFS
has for quite some time.  I always do mine manually anyway, so automatic
stuff really doesn't matter to me.  Just pointing out a difference, if
it still exists.

>> strength as a weakness due to a volume portability corner case no SA in
>> his right mind would attempt.
>>
>> The proper way to do this is to perform an xfsdump of the filesystem to
>> a file, create a new XFS with the proper stripe geometry in the new
>> storage location (which takes all of 1 second BTW), then xfsrestore the
>> dump file.
> 
>    Damn the proper way, Stan, if it's inconvenient one, and some
> better results can be automagically achieved using another way. Which
> one is more proper then? )

It depends on how much one values his data integrity and performance,
and what one considers "inconvenient".  If it takes 3 hours to move a
large filesystem to another array with your pvmove method and you end up
with performance problems afterward, what's the real human time
difference if it takes 5 hours to do it correctly with xfsdump/restore
and an mkfs.xfs?

BTW, if you use an aligned EXT4, you have the same problem with the new
RAID geometry.  But EXT4 doesn't have integrated dump/restore
facilities, so you'd have to use something like tar, which will take
many times longer due to all the system calls.  xfsdump/restore send
commands directly to the filesystem driver--no user space calls.

>    I see no point in arguing just to argue.

Accepting the fact there are people on this list who have far more
knowledge of XFS internals than yourself would be a good start.

-- 
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html