[ENBD] enbd + fr1 question/explanation
Peter T. Breuer
ptb at inv.it.uc3m.es
Wed May 17 17:36:21 MDT 2006
"Also sprach Ste:"
> Hi, i am experimenting an ENBD + raid1 (fr1) cluster at my university. I
> am a student. :-)
>
> A little introduction:
> I configured ENBD on 3 servers:
>
> server 1: share a 40 gb hd via ENBD
> server 2: share a 40 gb hd via ENBD
> server 3: groups the server1's hd and the servers'2 ones to,
> respectively, /dev/nda and /dev/ndb
>
> On server 3:
> /dev/nda and /dev/nbd are the two components of a two disks raid1 made
> with the fr1 module.
Which kernel? And driver versions? (if known).
> Now to make the raid I type "mkraid /dev/md0".
>
> All seems to be okay. But look at this:
>
> root at data:~# cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid5]
> read_ahead 1024 sectors
> md0 : active raid1 nda[1] ndb[0]
> 104388 blocks [2/2] [UU]
> [==========>..........] resync = 50.1% (52672/104388)
> finish=4.8min speed=760K/sec
> unused devices: <none>
>
>
> So the fr1 module is syncing the two components of the array.
Are you sure that is fr1? What is the evidence that tells you so? (I
don't recall the output format, but I'm pretty sure it's close to
identical to raid1).
> The first question is: *what* is syncing since the raid is just created?
I seem to recall raid always syncs an array at creation. Otherwise the
two sides wouldn't be equal (ditto, mumble, for other raid types).
> The second question, and the bigger problem: why, every time i run
> "raidstart /dev/md0", also start a total resync?
Well, that's a more interesting question. I guess it depends how the
array was stopped! Make sure it is shut down cleanly. If it is, the
event stamps on all components should be equal, and reassembly should
do no resync.
> A total resync of the
> two 40 gb disks take about 10 hours (we work with some pentium 133) and
> we can't have a total resync every time we reboot the server.
>
> I do not see the point: why a resync every time the raid is started?
You'll have to tell me. Look at the kernel messages saying why.
Peter
More information about the ENBD
mailing list