2

I'm running RAID 1 on an Adaptec 6405. I'm trying to decide if I need to install the ZMCP on the card to provide Cache protection. Adaptec's ZMCP is the equivalent of a BBU - battery backup for the cache.

I've enabled write caching in the controller bios to ensure the system performs well.

I can understand cache protection being required for stripping. But is it required for mirroring?

Is the risk of running RAID 1 without cache protection (a BBU or Adaptec's ZMCP) any greater than running a machine with a normal SATA controller?

If anyone has a Adaptec 6405 with the AFM 600 daughter board would you be able to tell me if the AFM 600 protudes off the side of the card, and if so by how much?

The motherboard only has one PCI Gen2 slot that the Adaptec 6405 card fits in and in this slot the side on which the ZMCP goes is only a centimeter or so from the side of the case.

4 Answers 4

1

Cache protection is about protecting what is in the controller cache "before" it is written to the disks. So if you have write cache enabled on an array, then the data is written into the DDR memory on the controller ... then written do the disk (when the disks are not so busy). This principles remains no matter what RAID level is used. So if you want to protect the data that the OS has written to the disks, but the controller has not yet physically written to the disks, then you need cache protection. BTW: running any spinning disks without write cache is as slow as a wet week. N

1

I can understand cache protection being required for stripping. But is it required for mirroring?

Technically it is not required for either. It just increases performance and risk. If you want to be 100% sure then you:

  1. Do not use writing caching on the RAID card or use a BBU/flashbackups/ZMCP.
  2. Turn off write caching in the drives itself.

But RAID is not about being 100% safe. RAID is about two potential things:

  1. Keeping you data intact and access able even when a disk fails. (At least until you can do emergency maintenance. E.g. shortly after business hours).
  2. And very sometimes it is aboutincreasing performance (e.g stripes, or RAID10, 50, 60 , ...reading from RAID5/6)

To summarize: No, it is not required for a mirror.

Is the risk of running RAID 1 without cache protection (a BBU or Adaptec's ZMCP) any greater than running a machine with a normal SATA controller?

Nope. I would guess it is about the same.
(Which excludes the risk of the RAID card failing).

1

A Write cache is a volatile memory (usually RAM) that the OS and disks use to consolidate and cache write actions into. Generally, everything that's in the cache, has not yet been written to disk. If power is lost to this cache, it will lose its contents, and by extend, you will lose some data.

If your controller has a backup battery, then the write cache will be retained in the event of a power outage until the next boot, and then written to disk(s). The RAID level has nothing to do with this.

If you don't have a backup battery you'll lose a chunk of data that was still in cache. Neither the filesystem nor RAID will know exactly what was in the cache, and as such you'll lose that data. This is a problem with every RAID level, even with RAID1 or RAID5. This problem is more commonly known as a RAID Write Hole.

In short: If you use a write cache, you will need a backup battery for that cache. If you don't use a write cache, you won't. RAID-level is unrelated.

1

In RAID1, if power is lost and some data in the write cache was written to one hard drive but not another, the drives will have disagreeing data for some blocks. I think that, depending on what exact RAID system you’re using, it’s possible that the system will balance reads between both drives. If the system does not “scrub” the array after a dirty shutdown before returning data to the reader, it might return different data for the same block in subsequent reads. I.e., you might read a file and see data on one disk, flush your read caches, and then read the same file again and get the data from the other disk which could be different.

I think (not sure, though) that when I’ve seen Linux’s MD (software RAID) after a reboot it seems to automatically run a scrub and actually refuse to return particular blocks until it verifies that each block is scrubbed. But I’m not sure if that was what it was actually doing. Also, I don’t know how hardware RAID controllers handle this situation.

Note that even if this scrubbing happens, if your write cache does not preserve the order of writes to each disk, the filesystem might be corrupted, even if it’s journaled. I assume that the write cache you are referring to lies to the OS about writes actually completing, meaning that any assumptions a filesystem makes about persistence are purposefully being violated for the sake of performance. It seems that battery backups are intended to ensure that writes that the filesystem thinks were completed actually do complete in such a way that when the array is reassembled the data that the filesystem thought was written is returned on reading.

Sorry, I don’t have answers, I raise the concerns/questions that would worry me in this scenario.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .