On Mon, 2012-01-30 at 01:50 +0000, Lou Picciano wrote:
> Bayard, 
> Indeed, you did answer it - and thanks for getting back to me - your 
> suggestion was spot ON! 
> However, the simple zpool clear/scrub cycle wouldn't work in our case - at 
> least initially. In fact, after multiple 'rinse/repeats', the offending file 
> - or its hex representation - would reappear. In fact, the CHSKUM errors 
> would often mount... Logically, this seems to make some sense; that zfs would 
> attempt to reconstitute the damaged file with each scrub...(?) 

As the truth is somewhere in between, I'll insert my comment
accordingly. You should only see the errors continue if there's a
dataset with a reference to the version of the file that creates those
errors. I've seen this before: until all of the datasets are deleted,
the errors will continue to be diagnosed, sometimes presented without
databaset names, which might be considered a bug (it seems wrong that
you don't get a dataset name for clones). You wouldn't happen to have
preserved output that could be used to determine if/where there's a bug?

> In any case, after gathering the nerve to start deleting old snapshots - 
> including the one with the offending file - the clear/scrub process worked a 
> charm. Many thanks again! 
> Lou Picciano 
> ----- Original Message -----
> From: "Bayard G. Bell" <buffer.g.overf...@gmail.com> 
> To: z...@lists.illumos.org 
> Cc: zfs-discuss@opensolaris.org 
> Sent: Sunday, January 29, 2012 3:22:39 PM 
> Subject: Re: [zfs] Oddly-persistent file error on ZFS root pool 
> Lou, 
> Tried to answer this when you asked on IRC. Try a zpool clear and scrub 
> again to see if the errors persist. 
> Cheers, 
> Bayard

Attachment: signature.asc
Description: This is a digitally signed message part

zfs-discuss mailing list

Reply via email to