MirrorUX feasibility limits for 500+ GB FS on JBODS?

[John Rayl]

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

[DCE]

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.

[Jeff Schussele]

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

[Bill Hassell · Accepted solution]

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.

[John Rayl]

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! :)

[Bill Hassell]

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.