Re[2]: [zfs-discuss] Can't remove corrupt file

2006-07-21 Thread Robert Milkowski
Hello Bill,

Friday, July 21, 2006, 7:31:25 AM, you wrote:

BM On Thu, Jul 20, 2006 at 03:45:54PM -0700, Jeff Bonwick wrote:
  However, we do have the advantage of always knowing when something
  is corrupted, and knowing what that particular block should have been. 
 
 We also have ditto blocks for all metadata, so that even if any block
 of ZFS metadata is destroyed, we always have another copy.
 Bill Moore describes ditto blocks in detail here:
 
 http://blogs.sun.com/roller/page/bill?entry=ditto_blocks_the_amazing_tape

BM Right.  And I should point out that if Eric had been running build 38 or
BM later, this data corruption would not have happened - it would have been
BM automatically repaired using ditto blocks (the bad block was a L2
BM indirect block - of which there would have been 2 copies).

However possibly something is broken there as I see on two different
servers (v240, T2000) CKSUM errors for ditto blocks on daily basics
and it's hard to belive I have a problem with hardware and it hits
only metadata blocks. More at:

http://www.opensolaris.org/jive/thread.jspa?threadID=9846tstart=0

-- 
Best regards,
 Robertmailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re[2]: [zfs-discuss] Can't remove corrupt file

2006-07-21 Thread Robert Milkowski




Hello Gregory,

Friday, July 21, 2006, 3:22:17 PM, you wrote:







After reading the ditto blocks blog (good article, btw), an idea occurred to me:

Since we use ditto blocks to preserve critical filesystem data, would it be practical to add a filesystem property that would cause all files in a filesystem to be stored as mirrored blocks?

That would allow a dual-copy behavior selectable on a filesystem boundary even in a vdev pool.

That could be handy for those that have a little bit of critical data and a lot of not-so-critical data.






IIRC that's already planned.



--
Best regards,
Robert  mailto:[EMAIL PROTECTED]
   http://milek.blogspot.com



___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss