On Aug 22, 2010, at 3:57 PM, Ian Collins wrote:
> On 08/23/10 10:38 AM, Richard Elling wrote:
>> On Aug 21, 2010, at 9:22 PM, devsk wrote:
>>
>>> If dedup is ON and the pool develops a corruption in a file, I can never
>>> fix it because when I try to copy the correct file on top of the corrupt
On 08/23/10 10:38 AM, Richard Elling wrote:
On Aug 21, 2010, at 9:22 PM, devsk wrote:
If dedup is ON and the pool develops a corruption in a file, I can never fix it
because when I try to copy the correct file on top of the corrupt file,
the block hash will match with the existing blocks a
On Aug 21, 2010, at 9:22 PM, devsk wrote:
> If dedup is ON and the pool develops a corruption in a file, I can never fix
> it because when I try to copy the correct file on top of the corrupt file,
> the block hash will match with the existing blocks and only reference count
> will be updated. T
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of devsk
>
> What do you mean original? dedup creates only one copy of the file
> blocks. The file was not corrupt when it was copied 3 months ago.
Please describe the problem.
If you copied the
You are saying ZFS will detect and rectify this kind of corruption in a
> deduped pool automatically if enough redundancy is present? Can that fail
> sometimes? Under what conditions?
>
> I would hate to restore a 1.5TB pool from backup just because one 5MB file
> is gone bust. And I have a known g
> > From: zfs-discuss-boun...@opensolaris.org
> [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of devsk
> >
> > If dedup is ON and the pool develops a corruption
> in a file, I can
> > never fix it because when I try to copy the correct
> file on top of the
> > corrupt file,
> > the b
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of devsk
>
> If dedup is ON and the pool develops a corruption in a file, I can
> never fix it because when I try to copy the correct file on top of the
> corrupt file,
> the block hash will match
If dedup is ON and the pool develops a corruption in a file, I can never fix it
because when I try to copy the correct file on top of the corrupt file,
the block hash will match with the existing blocks and only reference count
will be updated. The only way to fix it is to delete all
snapshots (t