zfs discuss - Apr 2007 - Scrubbing a zpool built on LUNs

I''m building a system with two Apple RAIDs attached. I have hardware
RAID5 configured so no RAIDZ or RAIDZ2, just a basic zpool pointing at the four
LUNs representing the four RAID controllers. For on-going maintenance, will a
zpool scrub be of any benefit? From what I''ve read with this layer of
abstration ZFS is only maintaining the metadata and not the actual data on the
drives. What''s the best practice to keep the data healthy? (scrub,
import/export, etc..) Also, where are the replicas of the metadata stored in
this configuration? Can that be backed up?

Thanks.
 
 
This message posted from opensolaris.org

> I''m building a system with two Apple RAIDs attached. I have
hardware
> RAID5 configured so no RAIDZ or RAIDZ2, just a basic zpool pointing at
> the four LUNs representing the four RAID controllers. For on-going
> maintenance, will a zpool scrub be of any benefit?
If some problem is causing data corruption, the scrub would be able to
detect it and notify you (though it would not necessarily be able to
correct it since most of your data will be non-redundant).  That''s
still
of value in many cases.  The earlier you know about it, the less data is
likely to be affected, and the greater chance you have of being able to
repair it through other means (backups, hopefully).

Also, in-pool metadata should be redundant (via ditto blocks).  Errors
in such data can be detected and repaired during a scrub.
> From what I''ve read with this layer of abstration ZFS is only
> maintaining the metadata and not the actual data on the drives.
I''m not sure what "maintaining" means here.  The actual data
is still
tracked and checksummed.  But since it is non-redundant, ZFS does not
have sufficient information to repair the data if errors are found.
> What''s the best practice to keep the data healthy? (scrub,
> import/export, etc..)
Scrub can notify you of problems that are seen.  Backups are also
important.  Otherwise, keep the underlying storage as healthy as
possible.
> Also, where are the replicas of the metadata stored in this
> configuration?
The pool configuration is stored on disks that are members of the pool,
and you have four "disks".

Because of ditto blocks, the in-pool metadata is duplicated (or
triplicated).  Since you have multiple luns in your pool, the redundant
copies should be stored on different luns.
> Can that be backed up?
Not separately from the data, no.  And I don''t know that
there''s
anything useful that could be done with it even if you did.  You can''t
recreate a pool in a way to read old data from it....

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Hello Darren,

Saturday, April 28, 2007, 1:03:00 AM, you wrote:


DD> Also, in-pool metadata should be redundant (via ditto blocks).  Errors
DD> in such data can be detected and repaired during a scrub.


DD> Because of ditto blocks, the in-pool metadata is duplicated (or
DD> triplicated).  Since you have multiple luns in your pool, the redundant
DD> copies should be stored on different luns.


To clarify - ditto blocks are used: 3 copies for pool metadata, each
copy on differen lun if possible, 2 copies for each file system
metadata with each copy on different lun. This means that file system
meta data corruptions should self-heal in a non-redundand config
(symlinks being an exception now, but there''s RFE to fix it).

-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com