Question about gmirror

V

vincepoy

I have a question about gmirror, I have read the how-to's:

Assuming my original drive is ad0 so I add a identical drive as ad2:

1) Do both drives have to be the same make/model or do they just have to be the same capacity?

2) for ad2, do I need to do the fdisk/disklabel/newfs on it or will it basically do a physical sector by sector copy of ad0?

3) what happens if I did:
[cmd=] fdisk -B -b /boot/boot0 ad0[/cmd]
[cmd=] bsdlabel -B ad0s1 [/cmd]
or should it actually be gm0 and gm0s1, does it update both
drives or would it be limited to ad0?

4) would there be any issues trying to mount ad2 slices as read-only just to make sure the data is there?

5) I've read that with 8.0-STABLE, load is supposed to be better than round robin, is there a way to switch from round robin to load assuming I started with:
gmirror label -v -b round-robin gm0 /dev/ad0
do I simply just do gmirror label -v -b load gm0 /dev/ad0
or do I have to gmirror clear /dev/ad0 first but wouldn't that destroy all data in the mirror?

6) What recommend performance tweaks are there to maximize performance?

Thanks!
 
vincepoy said:
1) Do both drives have to be the same make/model or do they just have to be the same capacity?
Click to expand...
No. They don't even have to be the same capacity. If ad2 is larger than ad0 that should be fine too.

vincepoy said:
2) for ad2, do I need to do the fdisk/disklabel/newfs on it or will it basically do a physical sector by sector copy of ad0?
Click to expand...
No. When you add ad2 to the existing gmirror volume, the volume's mbr, bsdlabel, and file system will be sector by sector copied to ad2.


vincepoy said:
3) what happens if I did:
[cmd=] fdisk -B -b /boot/boot0 ad0[/cmd]
[cmd=] bsdlabel -B ad0s1 [/cmd]
or should it actually be gm0 and gm0s1, does it update both
drives or would it be limited to ad0?
Click to expand...
If ad0 is already a member of a gmirror volume then you shouldn't fiddle with it directly.

vincepoy said:
4) would there be any issues trying to mount ad2 slices as read-only just to make sure the data is there?
Click to expand...
No, that's fine.

vincepoy said:
6) What recommend performance tweaks are there to maximize performance?
Click to expand...
If your chipset supports AHCI, enable ahci(4) and add this to sysctl.conf:
Code: 
vfs.read_max=32
 
Thanks for the answers. However, it seems the answer to #4 might not be correct as assuming ad2 is the second drive, and ad0 is the first drive that is part of gm0 already, as /dev is automatically created, there won't be a ad0* or ad2* devices in /dev for one to mount unless one deactivates ad2 from gm0. The other thing is that, would there be a data corruption if a shutdown -r now was issued if the status was DIRTY since sometimes, one will forget to check gmirror status before doing the reboot after a world build or a new kernel build.
 
vincepoy said:
assuming ad2 is the second drive, and ad0 is the first drive that is part of gm0 already, as /dev is automatically created, there won't be a ad0* or ad2* devices in /dev for one to mount unless one deactivates ad2 from gm0.
Click to expand...
Correct, sort of. You should see ad0 and ad2, but you won't see ad0s1, etc. Either way, you need to remove the provider from the array before you poke around with it directly, and when you readd it, all data will be synced again.

vincepoy said:
The other thing is that, would there be a data corruption if a shutdown -r now was issued if the status was DIRTY
Click to expand...
That's never happened to me, and I've done it a few times with my array...
 
I ran numbers on a new box I'm getting ready a week or two ago. It's configured with 2 Seagate 400 gig IDE drives with gmirror. Here are the results:

Code: 
bcserver# sysctl vfs.read_max ; dd if=srcd1.iso of=/dev/null bs=1M
vfs.read_max: 8
238+1 records in
238+1 records out
250138624 bytes transferred in 9.195314 secs (27202837 bytes/sec)

bcserver# sysctl vfs.read_max ; dd if=srcd2.iso of=/dev/null bs=1M
vfs.read_max: 16
238+1 records in
238+1 records out
250138624 bytes transferred in 7.897333 secs (31673810 bytes/sec)

bcserver# sysctl vfs.read_max ; dd if=srcd3.iso of=/dev/null bs=1M
vfs.read_max: 32
238+1 records in
238+1 records out
250138624 bytes transferred in 8.199721 secs (30505748 bytes/sec)

bcserver# sysctl vfs.read_max ; dd if=srcd4.iso of=/dev/null bs=1M
vfs.read_max: 64
238+1 records in
238+1 records out
250138624 bytes transferred in 8.088560 secs (30924988 bytes/sec)

bcserver# sysctl vfs.read_max ; dd if=srcd5.iso of=/dev/null bs=1M
vfs.read_max: 128
238+1 records in
238+1 records out
250138624 bytes transferred in 8.080766 secs (30954816 bytes/sec)

bcserver# ls -l srcd?.iso
-rw-r--r--  1 root  wheel  250138624 Jan 21 16:14 srcd1.iso
-rw-r--r--  1 root  wheel  250138624 Jan 21 16:15 srcd2.iso
-rw-r--r--  1 root  wheel  250138624 Jan 21 16:15 srcd3.iso
-rw-r--r--  1 root  wheel  250138624 Jan 21 16:15 srcd4.iso
-rw-r--r--  1 root  wheel  250138624 Jan 21 16:15 srcd5.iso

bcserver# md5 srcd?.iso
MD5 (srcd1.iso) = 39316d440a92e24c896e59a3a811230e
MD5 (srcd2.iso) = 39316d440a92e24c896e59a3a811230e
MD5 (srcd3.iso) = 39316d440a92e24c896e59a3a811230e
MD5 (srcd4.iso) = 39316d440a92e24c896e59a3a811230e
MD5 (srcd5.iso) = 39316d440a92e24c896e59a3a811230e

I ripped the system rescue cd with dd, then copied that file to each of the 5 files shown. I then rebooted to eliminate the possibility of disk caching coming into play, then ran the above commands for each of the displayed vfs settings. The setting that's best for your system can only be determined AFAIK, by such experimentation.
 
aragon said:
Correct, sort of. You should see ad0 and ad2, but you won't see ad0s1, etc. Either way, you need to remove the provider from the array before you poke around with it directly, and when you readd it, all data will be synced again.


That's never happened to me, and I've done it a few times with my array...
Click to expand...

I'm running the February 1, 2010 -CURRENT and today, my kernel paniced so I rebooted from the db> which means it didn't sync before rebooting... So when it rebooted, gmirror said pending mount of /usr after the fsck so it does the fsck and then I see gmirror and then the kernel goes to the db> prompt which means it paniced so I try the reboot again and same problem so then I rebooted to single user mode, did the fsck /dev/mirror/gm0s1a and fsck /dev/mirror/gm0s1d and it fixed the errors and marked both as clean. Was I supposed to remove the providers (ad0) and (ad2) before doing the fsck or did I do it correctly as it seems like gmirror list and gmirror status did show it was degraded and it was synchronizing. It would seem if I did remove the providers and fsck ad0s1a, ad0s1d, ad2s1a, ad2s1d, there might be other problems if fsck had different errors on the slices in ad2.
 
Just curious what gmirror does if it was dirty or synchronizing and you issued a shutdown, what would happen to the data or does gmirror just continue after it reboots?
 
Yea, it continues from where it left off. My array takes about 2 hours to resync (1 TB), and I've often rebooted while it's a few percent into a resync.

It's like black magic really. I've had this array for almost 2 years now without any issues. It's seen me through a hard drive death too. I love gmirror. :)
 
Speaking about gmirror, is the HDD activity led supposed to be on even when it's 100% synchronized aka status is shown as COMPLETE? I'm using a pair of Seagate 2.5" 160GB PATA 5400RPM drives in my Dell notebook and it seems like the Hitachi 60GB 2.5" 7200RPM drives is a lot faster even in my dump/restore tests with the same amount of data which is 20GB, the dump/restore took 30 minutes on the Hitachi but like 2 hrs on the Seagate. I dumped from the Hitachi to the Seagate so I have more capacity as the first Hitachi drive had bad sectors that corrupted some data which was when I heard about gmirror so while the November 2004 build of 6.0-CURRENT worked, it didn't have the status option and only round-robin worked while load didn't really do anything so went to 8.0-CURRENT a few days ago. When I did my initial gmirror, it seemed to take 10 hours to sync or something. What I was concerned about is that when I did the single user fsck yesterday, it was ad0 that was syncrhonizing while ad2 was fine so hopefully it was copying the correct data as ad0 is my primary drive and ad2 is just the copy. When you fsck gm0 slices and it fixes them, does it really only fix one drive with the errors and then just get the data back from the other providers?
 
Ruler2112 said:
You know you just jinxed yourself dude... ;)
Click to expand...

Back on January 15, 2010 when my tripwire told me that there was a I/O error on certain files and I looked at my /mnt, /mnt/usr which are daily dump/restore of the / and /usr slices, I said the same thing since there was no data as it seems that the error prevented dump/restore from working so even though I was the one who wrote this method:

http://lists.freebsd.org/pipermail/freebsd-questions/2003-September/017846.html

It did backfire since I didn't factor in what would happen if the backup ran after a drive failure. :(

So I used frenzy's FreeBSD LiveCD with the ddrescue tool and basically recovered 99% as I lost about 100KB out of 20GB of data which is pretty good so I read about gmirror when I was searching for FreeBSD RAID and found the answer.
 
vince, HDD light shouldn't be solid when the array is in COMPLETE state. Maybe something else is consuming I/O.

It sounds like your Seagate is much older than the Hitachi? An older (smaller) drive will pretty much always be slower for the same RPM. Platter density has a large influence on access times and throughput. You might want to use the prefer algorithm and give priority to the Hitachi.
 
Not sure but it seems that without gmirror, the HDD light goes on and off but with gmirror, the HDD light is on solid even during the complete state. It appears that diskcheckd is what is causing the HDD light to remain on, maybe diskcheckd from ports/sysutils doesn't work well with gmirror?

Actually, the Hitachi is older than the Seagate as Hitachi, Fujitsu and Toshiba were the only manufacturers of 2.5" drives and Hitachi always came out with the 7200RPM models which the 60GB was the last PATA model. Western Digital and Seagate came out with 2.5" models and they were the only ones who had PATA 160GB drives except they all ran at 5400RPM and not 7200RPM but they had less platters inside and from reviews, it's faster than the 7200RPM drives. The 160GB does 540Mbit/sec while the 60GB does 518Mbit/sec
from the spec sheets. Perhaps the issue is because of diskcheckd as diskcheckd seems to work fine when there is no gmirror involved for some reason.
 
vincepoy said:
Not sure but it seems that without gmirror, the HDD light goes on and off but with gmirror, the HDD light is on solid even during the complete state.
Click to expand...

It's easy enough to fix this... just take the side of your case off, find the wires going to the HDD light (usually red/white), trace them back to the motherboard, and unplug it. :e
 
Ruler2112 said:
It's easy enough to fix this... just take the side of your case off, find the wires going to the HDD light (usually red/white), trace them back to the motherboard, and unplug it. :e
Click to expand...

Except in my case, the HDD is really constantly being read because of ports/sysutils/diskcheckd which for some odd reason works correctly when I'm not using gmirror. If I stopped diskcheckd, the HDD led is normal again. diskcheckd was something that was part of FreeBSD 5.0 and later went to ports. Not sure what is causing diskcheckd to constantly read the drives.
 
You must log in or register to reply here.
Back
Top