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@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
