Topic: Raid1 Disk Syncing

[juan]

is it normal for raid1 to take as long as 3days to sync on sme or is that the same on all linux boxes i meen thake a look @ the following argument...

there is only +/- 600mb of data on a fresh install of SME it look like it sync the blocks and not the data is this true? that can only be the explination for taking 3days to sync 200gb drives with only +/- 600mb of data on them  

can some one shed some light on this?

Cheers Juan

[stefan24]

Hi Juan,

sure! SME syncs the whole disks and not only the used data.

3 days seems a bit long. Maybe you don't have DMA enabled?
But I remember, that even 9 GB SCSI lasted quite some time, when I tested RAID 1 mirroring some time ago.

[jackl]

Any one come up with definite time scale on this?
I have two 80Gb hard drives mirrored and it looks like it is going to take in excess of 24 hours for them to sync is this normal?

[crazybob]

Not that I know what to do about it, But it does seem like it is taking a long time. How much data is invloved? I had a pair of 200GB IDE drives with about 40GB of data and it took about 4 hours to complete.

Bob

[Reinhold]

Code: [Select]

cat /proc/mdstat

...will give you an idea of what it does now
and how long it may still take...

Code: [Select]

hdparm -t /dev/mdx
...with x 0,2,3 will give you the maximum speed it can read/write

80Gb hard drives mirrored and it looks like it is going to take in excess of 24 hours

...unless you've got a 266MHz CPU i'd believe this "far too long" - but what else does go on?  64k RAM? Virus-scan? Mail-scan ?

use top ... or Charlie Brady's new contrib htop

Reinhold

[NickR]

It's worth remembering that regardless how fast the disks are, the sync is throttled to ~10Mbytes/sec.
Doing a cat /proc/mdstat will tell you what the current throughput is, along with a progress bar.

[jackl]

I used the raidmonitor rpm to watch the progress and my original estimate was wrong but it still took 12 hours. The mother board is a new Asrock (SIS Chipset) quite cheap so maybe the ide controller is not state of the art as the max tranfer rate was ~1800K/sec during the raid build. The system is a P4 2.8ghz 512Mb RAM and had stock SME only loaded at the time of synchronisation. It has just occured to me, I have both disks on the same IDE channel perhaps this accounts for slow raid build time?. I needed to retain the cd drive on the second channel and was afraid this would lower the speed of any hard disk on that channel.
Alas it is finished now and performance wise it seems to running fine.
Thanks everybody for your help.

Regards
Jack

[NickR]

Since SME6, I always build my servers with the RAID disks on the same channel & it makes no measurable difference to performance, either while building the array or in normal use.  

Where it does make a difference is under heavy load. I've found that the array will often break with the disks on seperate channels claiming disk failure.  

It's wrong, the disk has always been fine.  I'm pretty sure that it's a timing bug somewhere, but I've yet to see it happen in disks on the same channel.

[Reinhold]

jackl,
NickR


I'm sure the advocates of "must be hardware Raid" cannot but scream at your "both disks on one cable" policy

But as NickR says... "measuring the stuff does prove there is little speed difference (if any) in master/slave settings with todays ide controllers/disks"

What does remain is the risk you run when the controller partially breaks...
your system will no longer boot if both HDs are on the same ide channel and that channel goes bad...
Sort of defeat's the whole Raid1 idea - IMHO that is.

While I happily put disks on master/slave for a raid5, I prefer the stuff to boot under (almost) all circumstances so it is HD1 IDE0:M and HD2:IDE1:M for my SME Raid1's.

Regards
Reinhold

P.S.: No I never had a dead controller where only one channel broke ... the only one where I had a "single channel failure" turned out to be a bad solder joint!

[NickR]

Reinhold

Hardware RAID is more often than not a single channel with all the disks on 1 cable.  The main benefit of hardware RAID is that the proccessing is carried out by dedicated hardware which (theoretically) confers better performance.

Don't forget that with SME software RAID, both IDE channels cannot be accessed simultaneously, the driver needs to switch channels to write the same data to the second disk.  This is where I suspect the timing bug resides.  There have been several reports on here of RAID arrays breaking when configured as HDA & HDC & I  experienced it myself on several machines on 5.1.2 & 5.6

Let's not lose sight of the fact that an SME server with software RAID is a cheap solution to the disk redundancy problem which you could easily spend 10x as much on - you get what you pay for!

[Reinhold]

Hardware RAID is more often than not a single channel with all the disks on 1 cable.

Huh?
- this is 2005 !
Impossible with IDE and since SCSI is a bus and can arbitrate that would be comparing apples 'n oranges!
Name such a controller please!

If HDA+HDC "throw a fit" then it's your cabling - for sure and I haven't heard/read of any raid "timing bug" in 2.4.x kernel ...

Reinhold

[NickR]

Hardware RAID is more often than not a single channel with all the disks on 1 cable.

Huh?
- this is 2005 !
Impossible with IDE and since SCSI is a bus and can arbitrate that would be comparing apples 'n oranges!
Name such a controller please!

I was thinking of SCSI RAID controllers I have known eg. PERC/3 & Adaptec 2100S. I've never bothered with IDE hardware RAID personally.

If HDA+HDC "throw a fit" then it's your cabling - for sure and I haven't heard/read of any raid "timing bug" in 2.4.x kernel ...

It could be cable, I guess.  I've seen it on 4 machines now.  They got re-formatted to hda & hdb with the same cable & disks and are now stable.  Also odd that it's always been hda2 that gets disconnected from the array and it will always rebuild OK...  It may be that the problem is specific to certain motherboards &/or chipsets - I think all mine have been VIA chipsets for AMD's.
Here are 2 people who have had it on SME 6 recently:

http://forums.contribs.org/index.php?topic=25747.msg104375#msg104375

[Stefano]

is it normal for raid1 to take as long as 3days to sync on sme or is that the same on all linux boxes i meen thake a look @ the following argument...

there is only +/- 600mb of data on a fresh install of SME it look like it sync the blocks and not the data is this true? that can only be the explination for taking 3days to sync 200gb drives with only +/- 600mb of data on them  

can some one shed some light on this?

Cheers Juan

Hi Juan..

- original SME 6 kernel? maybe your chipset is not recognized.. check in /var/log/messages if you have some similar line:
..
VP_IDE: Unknown VIA SouthBridge, disabling DMA.
..
if so, a kernel upgrade is recommended

- each hd must be installed as primary on separate ide channel

HTH
Ciao

[jackl]

Hi All

Sorry for digging this up again but just powered up a test server previously loaded with SME6.5 configured with RAID 1 and noticed that the disks were busy synchronising.
 Using cat /proc/mdstat showed the process was going to take many hours despite the fact that they are only 4Gb drives. The data transfer rate was less than 1000k/sec.
The cause of this delay we found to be that the pppoe account and password were not set right and the server was continually trying to establish a ADSL connection seemingly using up substantial resources  doing so. After the account details were set correctly and a reboot the sychronisation of the hard disks took minutes with a data transfer rate >3000K/sec.
This problem would also appear to happen if you configure the server during initial setup as dedicated server-gateway using ppoe and leave it offline, then the synchronisation takes forever.
It is surprising that trying to establish a connection that's not there, should put such a load on the system. It would seem if you are configuring a new server with software RAID 1 it is best to initially configure it as a server only, wait for the disks to synch, and then configure it as a gateway if needed.
Hope this is of some help to somebody.

Regards
Jackl

ps this is just an observation, it would need several reloads to prove conclusively

[CharlieBrady]

Hardware RAID is more often than not a single channel with all the disks on 1 cable.

Really?

The main benefit of hardware RAID is that the proccessing is carried out by dedicated hardware which (theoretically) confers better performance.

There's really no such thing as hardware RAID. It's all software RAID, what's at issue is who wrote the RAID software, and where it runs. In so-called hardware RAID solutions, the RAID software runs in firmware on a co-processor.

There have been several reports on here of RAID arrays breaking when configured as HDA & HDC & I  experienced it myself on several machines on 5.1.2 & 5.6

I don't recall seeing any bug reports on this issue. Can you point me at one?