Roger, et al --
...and then Roger Heflin said...
% How big is your stripe size set to? The bigger the stripe size on the
% md40 main raid the closer it gets to linear.
I don't know ... and I don't know how to tell.
davidtg@jpo:~> sudo mdadm -D /dev/md40
/dev/md40:
Version : 1.2
Creation Time : Mon Aug 8 12:15:12 2022
Raid Level : raid0
Array Size : 3906488320 (3.64 TiB 4.00 TB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Aug 8 12:15:12 2022
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : -unknown-
Chunk Size : 512K
Consistency Policy : none
Name : jpo:40 (local to host jpo)
UUID : 4735f53c:7cdf7758:e212bec6:aa2942e8
Events : 0
Number Major Minor RaidDevice State
0 9 41 0 active sync /dev/md/md41
1 9 42 1 active sync /dev/md/md42
davidtg@jpo:~> sudo mdadm -E /dev/md40
/dev/md40:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
Is it the 512k chunk size?
%
% And I think I did miss one behavior that explains it being faster with
% larger, and not sucking as bad as I expected. On disks the internal cache
% is supposed to cache the entire track as it goes under the head, so when
Sounds familiar.
% you ask for the data theoriticaly requiring a seek the drive may already
% have the data still in its cache and hence not need to do a seek. The
% performance would then be ok so long as the data is still in the cache.
Right. Everything is awesome when the data is cached :-)
% But given your tests md40 at best gets close to the underlying raids
% performance. When linear the underlying performance should be roughly
% equal.
Now that I understand linear, that makes sense.
Thanks again & HANN
:-D
--
David T-G
See http://justpickone.org/davidtg/email/
See http://justpickone.org/davidtg/tofu.txt
