Michael Shadle wrote:
On Mon, Mar 30, 2009 at 4:00 PM, David Magda <dma...@ee.ryerson.ca> wrote:

There is a background process in ZFS (see "scrub" in zpool(1M)) that goes
through and make sure all the checksums match reality (and corrects things
if it can). It's reading all the data, but unlike hardware RAID arrays, it
only checks the actual space used.

It basically goes through the file system structure hierarchy, and if
there's an unused space on the array it doesn't bother--since no data blocks
point to it, there's nothing to check. The scrubbing process is the same
whether you're using mirrors, RAID-Z1, or RAID-Z2. It can be kicked off
manually or you can launch it via cron / SMF.

Not sure about tuning (e.g., allocating bandwidth / priority). If you start
a scrub the output of "zpool status" will give the progress (%) and ETA to
finish.

There is (was?) a bug where creating a new snapshot reset the scrub.

Well basically I am trying to analyze giving up 1/7th of my space for
the off chance that one drive fails during resilvering. I just don't
know what kind of time to expect for a resilver. I'm sure it also
depends on the build of nevada too and various bugs...

Resilver performance is constrained as follows:
1. priority of other activity, resilvering occurs at a lower priority than most
   other file system operations

   2. write bandwidth of the drive being resilvered

   3. read iops of the source drives

Since you are only resilvering data, this may go fast, or may take a while.
One thing is certain: it is difficult to predict in advance.

Normally it seems like raid5 is perfectly fine for a workoad like this
but maybe I'd sleep better at night knowing I could have 2 disks fail,
but the odds of that are pretty slim. I've never had 2 disks fail, and
if I did, the whole array is probably failed / the actual unit itself
got damaged, and then probably more than the 2 disks have been
destroyed anyway.

As the disks get bigger, the odds become worse.  Seagate claims that a
1.5 TByte Barracuda 7200.11 has an UER of 10^-14.  Or, to put this in
layman's terms, expect an unrecoverable read for every 8.3 times you read
the entire disk. Fortunately, the UER seems to be a conservative specification.

Looks like there are two open requests for speeding up and slowing
down the resilvering process already. So it does not sound like you
can tune it. But it would be nice to have some sort of number to
expect.

The more you value your data, the more redundancy you will need.
-- richard

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to