topic Re: MirrorUX feasibility limits for 500+ GB FS on JBODS? in Operating System - HP-UX

MirrorUX feasibility limits for 500+ GB FS on JBODS?

John Rayl — Mon, 15 Aug 2005 14:45:01 GMT

Hi all UX'ers,

I have a rp3440/4 with a 14 slot dual SCSI channel JBOD connected and full of 300 GB disks.

The customer was cheap and would not buy a RAID. So I am stuck with MirrorUX for any sort of protection.

I have a VG with three 300 GB disks in it and one ~900 GB lvol. Yes, they want/need this size lvol.

Mirroring this to disks on the other controller is going to take a while.

I am just curious what the opinions are of the feasibility of MirrorUX on large lvols like this as well as beyond the 1 TB barrier.

Is MirrorUX only useful for root disks or small lvols?

Thanks,

-John

Re: MirrorUX feasibility limits for 500+ GB FS on JBODS?

DCE — Mon, 15 Aug 2005 14:57:40 GMT

MirrorUX will/does work on large volumes and non root vg's. Once you completed your initial mirror, you should not notice any appreciable difference, except that read might be a bit faster.

Re: MirrorUX feasibility limits for 500+ GB FS on JBODS?

Jeff Schussele — Mon, 15 Aug 2005 15:03:28 GMT

Hi John,

As you've figured out the initial mirror will take some time. But after that you'll hardly notice any difference in write times. BUT what you may notice is faster read times because now the host can read from either of 2 places. LVM looks at the read queues & places the next request in the smaller queue - hence faster access times than w/o Mirror-UX.
And, yes, I would agree that a RAID would be a somewhat better choice in this scenario. But I don't think you'll pay a big penalty using a JBOD - I would've definitely recommended fibre channel however - but even a SCSI RAID would probably be noticeably slower than a FC JBOD.

My $0.02,
Jeff

Re: MirrorUX feasibility limits for 500+ GB FS on JBODS?

Bill Hassell — Mon, 15 Aug 2005 15:13:20 GMT

Mirror/UX works with terabyte sized volume groups and lvols. Actually, Mirror/UX doesn't care a thing about the size of a disk. It is a driver-level procedure that initiates a second (or even a third) write to the mirror disk(s) and waits until all are complete. Mirroring covers any sized lvol that is supported in the OS.

And to save an IMMENSE amount of time, be sure to create the lvol with the mirroring option on the same line, in other words, this:

lvcreate -L 900000 -m 1 vg09

(which takes just a few seconds)
and not:

lvcreate -L 900000 vg09
lvextend -m 1 /dev/vg09/lvol1

However, if the 900Gb lvol has already been created, then start the mirroring and let it cook for a few hours. Note that the mirroring task can be safely done on a running system. The updates to the mirror take place in such a way as to keep track of stale and synced extents automatically. This task will definitely slow down overall access during the sync tiome, but once complete, you'll not notice any measureable performance issues.

Re: MirrorUX feasibility limits for 500+ GB FS on JBODS?

John Rayl — Mon, 15 Aug 2005 16:06:08 GMT

Bill,

Thanks for the info on building the mirror at lvol creation time! HUGE time saver.

Initially I had thought of that but wondered how I could assign which disks were the mirrors.

I tried it and it worked!

Wear that Olympian wreath thingie proudly! :)

Re: MirrorUX feasibility limits for 500+ GB FS on JBODS?

Bill Hassell — Mon, 15 Aug 2005 20:06:26 GMT

Some people will wonder why this works since no data is actually copied between the disks. The reason is that when the lvol is first created, nothing on the disk is defined so if you read from any location on the lvol, you get random data. Same with the mirror(s). But write anything to the lvol and the mirrors are also written, defining that portion of the disk. So combining the mirror with creation means that all mirrors are 'synced' and will stay synced from now on.