[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-bugs
Subject:    Re: [osol-bugs] [zfs-discuss]  what's the story wtih bug #6592835?
From:       Nils Goroll <slink () schokola ! de>
Date:       2008-10-29 12:51:01
Message-ID: 49085C35.6020602 () schokola ! de
[Download RAW message or body]

Hi Graham,

> thanks for the detailed info. I've tried searching the zfs-discuss archive for both \
> the bug id and 'resilver',

I must say that when I tried a search, I did not immediately find what I had in 
mind, but at least I've found again a pointer to a good blog Entry by Jeff 
Bonwick explaining how it works:

http://blogs.sun.com/bonwick/entry/smokin_mirrors

> Does the severity of the problem depend on access / write patterns used

IMHO, yes. Trouble is that any zpool will fragment over time and there are no 
tools available yet to relocate ("defragment") data in it ...

> data is only ever added in a sequential fashion be less susceptible

... though I'd agree that a pool like this should show less fragmentation effects.

> Does the time taken to scrub the pool give some indication of the likely
 > resilvering time, or does that process walk a different kind of tree?

If I got this right, the two processes are similar in nature, but, again, others 
might come up with better answers.

I believe the fix for 6343667 is very likely to be ported back soon, but from 
outside Sun I can only guess.

Side note: I've once posted how to use SVM underneath ZFS, so in principle you 
could run ZFS on SVM mirrors (optionally with copies=2, which would quadruple 
your data, though (unless you can compensate with compression)). Though this 
would give you faster resyncs, you wouldn't get all the benefits of ZFS error 
recovery.

Nils
_______________________________________________
opensolaris-bugs mailing list
opensolaris-bugs@opensolaris.org


[prev in list] [next in list] [prev in thread] [next in thread]