Jens wrote:> Hi there,
>
> I am currently evaluating OpenSolaris as a replacement for my linux
installations. I installed it as a xen domU, so there is a remote chance, that
my observations are caused by xen.
>
> First, my understanding of "zpool [i]scrub[/i]" is "Ok, go
ahead, and rewrite [b]each block of each device[/b] of the zpool".
>
There are two types of scrub: read and rewrite. Read scrubs just
check data and make sure it is still readable. Rewrite scrubs do
the read check, then rewrite the data thus resetting the superparamagnetic
decay counter. ZFS does a read scrub.
> Whereas "[i]resilvering[/i]" means "Make sure, that all
[b]used blocks[/b] of the pool are in good health".
>
The term resilvering comes from the mirror making process (the
reflective coating on real mirrors is called "silver," so by
resilivering
a mirror you correct any defects in the reflective coating. Some
liberties are used when thus describing mirrored disks, where the
term resilver refers to the process of making both sides of the mirror
the same. Data is copied from one side of the mirror to the other.
Astute readers will recognize this as an opportunity for failures, and
they would be correct, but that is another blog...
Another term often used here is resync, which is perhaps a more
general term where we make something in sync with something else,
from a data perspective when we''re talking about storage.
> Please correct me, if I am wrong.
>
> To test, I created a zpool named tank, assigning it a whole 300GB physical
SATA disc as backend.
>
> I observed, that scrubbing my 300GB tank takes virtually no time, when tank
is empty. Using space of tank (say, by a 20 GB copy of /dev/zero) causes
scrubbing to take much longer.
>
Yep. ZFS will only scrub data. An empty pool has very little data,
so it will complete quickly. A full file system will take longer.
This is actually one of the big advantages of ZFS over other RAID
systems which have no understanding of where the data actually is.
RAID arrays, for example, will scrub an entire disk because they don''t
know what parts of the disk actually contain data.
> This is clearly not, what I want (now). I want zfs to check the whole
device for errors, not just the few bytes that happen to sit there. Is this a
bug, a misunderstanding or a terrible case of RTFM?
>
ZFS won''t do this, because it is only really concerned with data.
There are other ways to check media. For example the format
command will allow you do to non-destructive or destructive
media tests. I recommend non-destructive tests, normally.
> Another irrirating observation was, that scrubbing starts, then stalls for
a minute or so at 0.4 something percent and then continues.
>
Since ZFS is dynamic, its ability to determine how long a scrub
will take is somewhat imprecise. With later builds, ZFS records
how long it actually took, which might be a better predictor for
future scrubs (see below)
-- richard
> Any ideas / pointers / ... ?
>
> Jens
>
> ---
>
> bash-3.2# zpool status tank
> pool: tank
> state: ONLINE
> scrub: scrub completed after 0h0m with 0 errors on Sun Aug 3 18:46:51
2008
> config:
>
> NAME STATE READ WRITE CKSUM
> tank ONLINE 0 0 0
> c4d1 ONLINE 0 0 0
>
> errors: No known data errors
>
>
> bash-3.2# uname -X
> System = SunOS
> Node = opensolaris
> Release = 5.11
> KernelID = snv_94
> Machine = i86pc
> BusType = <unknown>
> Serial = <unknown>
> Users = <unknown>
> OEM# = 0
> Origin# = 1
> NumCPU = 1
>
> bash-3.2# cat /etc/release
> OpenSolaris 2008.11 snv_94 X86
> Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
> Use is subject to license terms.
> Assembled 17 July 2008
>
>
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>