1822513 Members
2551 Online
109642 Solutions
New Discussion юеВ

Re: Oldie but goodie...

 
SOLVED
Go to solution
Tim Medford
Valued Contributor

Oldie but goodie...

I have a L1000 sandbox server connected up to an old A3312A jbod disk enclosure. It has 8 x 9gb drives, only a single loop SCSI interface.

I'd like to make 2 volume groups, each 36gb in size. I'm not sure how to best handle the striping in this case. There's really no built in RAID capabilities on this old array.

If I just do a standard vgcreate with 4 physical volumes, will the data just fill them up sequentially?

I'd appreciate any suggestions you might have.

Thanks, Tim
8 REPLIES 8
Patrick Wallek
Honored Contributor
Solution

Re: Oldie but goodie...

You are correct, there is no raid capability on the old Jamaica's (the A3312A).

You have to do this when you create the LVs.

Let's say your disks are c10t0d0 - c10t3d0 for this LV. I'm trusting that you already have the VG created and can handle that part.

# lvcreate -L 36000 -i 4 -I 64 /dev/vg??

This will create a 36000MB LV striped across 4 disks in 64 KB chunks.



A. Clay Stephenson
Acclaimed Contributor

Re: Oldie but goodie...

If you have a second controller, you could split this into two separate busses.
You just do a vgcreate in the normal manner. If you want to improve perform stripe across the 4 PV's when you do your lvcreates.

e.g.

lvcreate -L 1000 -i 4 -I 64 -n lvol1 /dev/vg02

Will stripe across 4 drives in 64K chunks. 64K tends to be the optimum for vxfs regardless of vxfs blocksize.
Vxfs is extent based so blocksize is relatively unimportant.
If it ain't broke, I can fix that.
Jeff Schussele
Honored Contributor

Re: Oldie but goodie...

Hi Tim,

Yes, If you use the defaults & don't stripe them when you lvcreate (-i X -I X) the LVs, the system will fill the first PV defined in the vgcreate command & then on thru the others in the order they were added.

So vgcreate as normal & get all 4 in there, then to create a striped LV across all 4 with a stripe size of 64k - you'd run the following

lvcreate -i 4 -I 64 -n lv_name /dev/vg_name

You can also use the ditributed allocation policy (-D y)to uses extents from all PVs for the LV - i.e. extent #1 from PV #1 / extent #2 from PV #2 /etc.

lvcreate -D y -n lv_name /dev/vg_name

So either way will distibute the data across all PVs.
You may get a little better performance with striping - depending on just what kind of data will live there.

HTH,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Jeff Schussele
Honored Contributor

Re: Oldie but goodie...

I should have added that to use the distributed allocation policy - you HAVE to use PVG (Physical Volume Group) when you create the VG

vgcreate -g pvg_name /dev/dsk/cxtydz .....

And then when you create the LV you need to use PVG-strict allocatiom (-s g) when you create the LV

lvcreate -s g -D y -n lv_name /dev/vg_name

Doing it this way is called extent-based stripes.

Rgds,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Brian M Rawlings
Honored Contributor

Re: Oldie but goodie...

Tim: LV striping is the way to go. Extent-based 'striping' works as Jeff says, but the idea is to spread the I/O across multiple spindles.

If you do LV striping with a 64K block size, each successive 64K block gets handed to the next spindle, and the next, until it returns to the first. This means that writes will spread across multiple spindles.

If you do Extent-based striping, all your 64K blocks keep going to one spindle until you completely write an entire extent, generally 4MB (by default). Then you move to the next define spindle and do successive I/Os to it until you've moved another massive extent. You can see that, whenever a write is smaller than 4MB (quite often), you'll not do any striping at all.

So, they are certainly both options, but I'd be surprised if you would see almost any improvement from Extent-based striping (in this case), and you almost always see a very significant performance boost from LV striping. Since it's a 'sandbox system', try it both ways, and without any striping at all, and let us know what you find, if you do.

Hope this clears up the difference, in case there was any confusion.

Regards, --bmr
We must indeed all hang together, or, most assuredly, we shall all hang separately. (Benjamin Franklin)
Jeff Schussele
Honored Contributor

Re: Oldie but goodie...

Very good point Brian.
I fully agree.

Rgds,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Patrick Wallek
Honored Contributor

Re: Oldie but goodie...

A point of clarification on LVM striping -- if you want to STRIPE AND MIRROR at the same time, then your only option is to use extent-based striping (lvcreate -D y ...). Regular striping (lvcreate -i xx -I xx ...) will NOT work with mirroring.

I know this doesn't apply to your situation, but just in case anyone else ever finds this thread and wonders.
Brian M Rawlings
Honored Contributor

Re: Oldie but goodie...

Right, Patrick makes the only good case for extent-based striping that I have heard. With JBOD, to do both mirroring and striping, it has to be extent-based.

In an array, where the array is doing the mirroring (or whatever RAID data protection), you don't have to use Mirrordisk (LVM mirroring), go with the LVM striping option across multiple LUNs for best performance.

Nice catch, Patrick, thanks, this needed clarification.

--bmr
We must indeed all hang together, or, most assuredly, we shall all hang separately. (Benjamin Franklin)