On Mon, Oct 15, 2012 at 6:21 PM, Jason Matthews <[email protected]> wrote:
> > > From: [email protected] [mailto:[email protected]] > > > > My point is most high end storage units has some form of data > > verification process that is active all the time. > > As does ZFS. The blocks are checksumed on each read. Assuming you have > mirrors or parity redundancy, the misbehaving block is corrected, > reallocated, etc. > > Right, I understand ZFS checks data on each read, my point is checking the disk or data periodically. > In my opinion scrubs should be considered depending on the importance > > of data and the frequency based on what type of raidz, change rates > > and disk type used. > > One point of scrubs is to verify the data that you don't normally read. > Otherwise, the errors would be found in real time upon the next read. > Understood, if full backups are executed weekly/monthly no scrub is required. > > Perhaps in future ZFS will have the ability to limit resource > > allocation when scrubbing like with BV where it can be set. Rebuild > > priory can also be set. > > There are tunables for this. > > Thanks, did not know will research, had a fairly heavy impact the other day replacing a disk.. > > > Also some high end controllers have "port" verify for each > > disk (media read) when using their integrated raid that runs > > periodically. Since in the world of ZFS it is recommended to use > > JBOD I see it as more than just the filesystem. I have never deployed > > a system containing mission critical data using filesystem raid > > protection other than with ZFS since there is no protection in them an > > I would much rather bank on the controller. > > > Unfortunately my parser was unable to grok this. Seems like you would > prefer > a raid controller. > Sorry, boils down to this, if ZFS is not an option I use a raid controller if data is important. In fact I do not like to be tied to a specific controller, zfs gives me the freedom to change at any point > > j. > > _______________________________________________ > OpenIndiana-discuss mailing list > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss > > _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
