Re: External Journal scenario - good idea?

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

 



Jeremy Rumpf wrote:

>
>Yea, that's the biggest issue facing use of these new large capacity drives. 
>Figuring out how to keep performance acceptable while maximizing utilized 
>space. Of course, at least with IDE drives, the cost of large capacity drives 
>is still relatively low (compared to SCSI). I also suspect it will be 
>dropping off in the future even more so as Maxtor is readying a line of 320GB 
>drives.
>
Goodness...  that's pretty huge.  I remember sort of salivating at the big 180GB SCSI
drives that came out a little while back.  Can't remember who made those, I think it
was WD or Seagate.

>>calculating parity data for a 4-5 drive array, and even a separate RAID1
>>array working behind the same RAID controller may suffer write
>>performance issues because the data has to be processed by the same RAID
>>controller to actually get written to the RAID1 drives.
>>
>
>I would hope that the controller design is such that it can handle enough 
>operations per second to satisfy its host interface (the SCSI connection 
>exported to the host machine). Some things to consider if I may.
>
Yep, hopefully.  I know from corresponding with Promise on the newer 
Ultratrak-SX8000 (I think
that's what they're called), they totally re-did the electronics to up 
the interface up to U160 SCSI
and increased the cache on the controller to I think 32MB.  I was 
wondering if it was just a matter
of replacing the controller itself (and docs for the new unit even show 
how to replace it), but they
stated that backplane, drive carriers, and more had to be replaced. 
 They offered to upgrade my
Ultratrak100-TX8 unit for $1350, which I declined.  For another $600 or 
so I could buy the whole
unit, and still have the Ultratrak100-TX8 too... ;)

Well I think we're getting ready to get a little better idea of the 
interface speed of this unit can deal
with.  We have offloaded the majority of the files stored on the 
external RAID unit to other storage,
reducing the total storage of the unit in use to approx 14GB.  I am 
almost finished creating a software
RAID pair of RAID1 drives, and partitioning it out (as /dev/mdp0), to 
copy the remaining filesystem to
it from the big unit (and also breaking the one large filesystem up into 
several partitions and mount points).

Once I get this RAID1 pair where I can boot and run from it, I will be 
taking the large unit offline, and
doing all kinds of experimenting with it.  My first major curiousity is 
just how fast this server can write to
the unit, so I'm going to create a 4-drive RAID0 array.  I suspect this 
will reveal whether the write bottleneck
is all due to being a RAID5 array, or that being only partly to blame. 
 I'll also do some other testing and see
what works well.

My impression right now is to build an 8-drive RAID0+1 (some call it 
RAID10) array.  While this will cut
our storage space nearly in half, the potential fault tolerance is 
better, and write performance should be better
without the parity overhead also.  We'll use this "drive" for our mount 
point(s) requiring a lot of space.

I'm also tempted to experiment with a combination of software and 
hardware RAID -- making four RAID1
arrays on the unit, then create a RAID0 array in linux with those.  I 
suspect letting the unit's RAID controller
handle both (RAID0 and RAID1) would be better though.

>
>Across the board, this is less intensive than RAID5 operation. The offsetting 
>factor here would be that the controller has to support one RAID5 set while 
>it has to support multiple RAID1 sets. I would bet to say that the load on 
>the controller itself would stay about the same using 4 RAID1 sets vs 1 huge 
>RAID5 set. The number of write operations dispatched to the drives would be 
>about the same aggregaed over time and you'd be saving the overhead of 
>calculating the parity information.
>
Yep.  I guess the main thing I was antsy about was losing the extra 
space.  But it won't
seem so great to have so much space if I went with a RAID5 array, and 
ever have two
drives fail on the RAID5 array.  At least with RAID0+1 I have a decent 
chance (6 out
of 7) of survival in that case.

>>But I am really not even sure that what we're seeing here is a problem
>>with the speed of the RAID controller.  From some other reading I have
>>done, it seems that grabbing up RAM to cache writes and combine it all
>>into one big write is something that the 2.4 kernel series is rather
>>notorious for.
>>
>
>Yes, the pagecache becomes a vaccumn cleaner during I/O intensive periods. 
>This is being looked into in the development series (cachiness tuning). One 
>thing maybe to try:
>
>http://people.redhat.com/alikins/system_tuning.html
>
>Specifically the section on tuning the I/O Elevator.
>
>www.missioncriticallinux.com/orph/ServerNotes.pdf 
>
>Also has some interesting notes in it.
>
Thanks for the URL's - good reading and good tips!

>
>
>One other thing, if your cache controller is set to run in "write back mode", 
>try disabling that. Write back caches on RAID controllers will 
>aggregate/delay writes as well. Might be worth looking into (I know it tends 
>to kill perfromance on my LSI MegaRaid at times).
>
Thanks - good idea, that was.  The drives are already write-caching, 
with 8MB cache on each drive.
Ought to be enough... ;)

It ought to get pretty exciting around here in another few hours... ;)

Thanks again for all the advice Jeremy.

vinnie




_______________________________________________

Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux