Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-23 Thread Jim Klimov
2012-01-22 22:58, Richard Elling wrote: On Jan 21, 2012, at 6:32 AM, Jim Klimov wrote: ... So it currently seems to me, that: 1) My on-disk data could get corrupted for whatever reason ZFS tries to protect it from, at least once probably from misdirected writes (i.e. the head landed not

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-23 Thread Jim Klimov
2012-01-23 18:25, Jim Klimov wrote: 4) I did not get to check whether dedup=verify triggers a checksum mismatch alarm if the preexisting on-disk data does not in fact match the checksum. All checksum mismatches are handled the same way. I have yet to test (to be certain) whether writing

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-22 Thread Richard Elling
On Jan 21, 2012, at 6:32 AM, Jim Klimov wrote: 2012-01-21 0:33, Jim Klimov wrote: 2012-01-13 4:12, Jim Klimov wrote: As I recently wrote, my data pool has experienced some unrecoverable errors. It seems that a userdata block of deduped data got corrupted and no longer matches the stored

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Jim Klimov
2012-01-21 0:33, Jim Klimov wrote: 2012-01-13 4:12, Jim Klimov wrote: As I recently wrote, my data pool has experienced some unrecoverable errors. It seems that a userdata block of deduped data got corrupted and no longer matches the stored checksum. For whatever reason, raidz2 did not help in

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Bob Friesenhahn
On Sat, 21 Jan 2012, Jim Klimov wrote: 5) It seems like a worthy RFE to include a pool-wide option to verify-after-write/commit - to test that recent TXG sync data has indeed made it to disk on (consumer-grade) hardware into the designated sector numbers. Perhaps the test should be

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Jim Klimov
2012-01-21 19:18, Bob Friesenhahn wrote: On Sat, 21 Jan 2012, Jim Klimov wrote: 5) It seems like a worthy RFE to include a pool-wide option to verify-after-write/commit - to test that recent TXG sync data has indeed made it to disk on (consumer-grade) hardware into the designated sector

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Bob Friesenhahn
On Sat, 21 Jan 2012, Jim Klimov wrote: Regarding the written data, I believe it may find place in the ARC, and a for the past few TXGs it could still remain there. Any data in the ARC is subject to being overwritten with updated data just a millisecond later. It is a live cache. I am not

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Jim Klimov
2012-01-21 20:50, Bob Friesenhahn wrote: TXGs get forgotten from memory as soon as they are written. As I said, that can be arranged - i.e. free the TXG cache after the corresponding TXG number has been verified? Point about ARC being overwritten seems valid... Zfs already knows how to

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Bob Friesenhahn
On Sun, 22 Jan 2012, Jim Klimov wrote: So far I rather considered flaky hardware with lousy consumer qualities. The server you describe is likely to exceed that bar ;) The most common flaky behavior of consumer hardware which causes troubles for zfs is not honoring cache-related requests.

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-21 Thread Jim Klimov
2012-01-22 0:55, Bob Friesenhahn wrote: On Sun, 22 Jan 2012, Jim Klimov wrote: So far I rather considered flaky hardware with lousy consumer qualities. The server you describe is likely to exceed that bar ;) The most common flaky behavior of consumer hardware which causes troubles for zfs is

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-20 Thread Jim Klimov
2012-01-13 4:12, Jim Klimov wrote: As I recently wrote, my data pool has experienced some unrecoverable errors. It seems that a userdata block of deduped data got corrupted and no longer matches the stored checksum. For whatever reason, raidz2 did not help in recovery of this data, so I rsync'ed

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-12 Thread Richard Elling
On Jan 12, 2012, at 4:12 PM, Jim Klimov wrote: As I recently wrote, my data pool has experienced some unrecoverable errors. It seems that a userdata block of deduped data got corrupted and no longer matches the stored checksum. For whatever reason, raidz2 did not help in recovery of this

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-12 Thread Jim Klimov
2012-01-13 4:26, Richard Elling wrote: On Jan 12, 2012, at 4:12 PM, Jim Klimov wrote: As I recently wrote, my data pool has experienced some unrecoverable errors. It seems that a userdata block of deduped data got corrupted and no longer matches the stored checksum. For whatever reason, raidz2

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-12 Thread Jim Klimov
2012-01-13 4:26, Richard Elling wrote: On Jan 12, 2012, at 4:12 PM, Jim Klimov wrote: Alternatively (opportunistically), a flag might be set in the DDT entry requesting that a new write mathching this stored checksum should get committed to disk - thus repairing all files which reference the

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-12 Thread Daniel Carosone
On Fri, Jan 13, 2012 at 05:16:36AM +0400, Jim Klimov wrote: 2012-01-13 4:26, Richard Elling wrote: On Jan 12, 2012, at 4:12 PM, Jim Klimov wrote: Alternatively (opportunistically), a flag might be set in the DDT entry requesting that a new write mathching this stored checksum should get

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-12 Thread Jim Klimov
2012-01-13 5:34, Daniel Carosone wrote: On Fri, Jan 13, 2012 at 05:16:36AM +0400, Jim Klimov wrote: Either I misunderstand some of the above, or I fail to see how verification would eliminate this failure mode (namely, as per my suggestion, replace the bad block with a good one and have all

Re: [zfs-discuss] ZFS Dedup and bad checksums

2012-01-12 Thread Jim Klimov
2012-01-13 4:26, Richard Elling wrote: On Jan 12, 2012, at 4:12 PM, Jim Klimov wrote: The problem was solved by disabling dedup for the dataset involved and rsync-updating the file in-place. After the dedup feature was disabled and new blocks were uniquely written, everything was readable (and