Use zpool status -v to see if any errors come up. Then you can use zpool scrub
to remove at least some of them. I have had luck with this in the past.
---Todd
On Nov 14, 2011, at 04:25 , <sbre...@hotmail.com> <sbre...@hotmail.com> wrote:
>
> Back to this topic, since I cannot touch snapshots I thought I could simply
> remove the corrupt files after the last snapshot, so the next incremental
> backup will notice the difference (i.e. no file) and overwrite the
> corrupt-and-removed files with valid ones. This was the plan.
>
> However, while checking for corrupt files, "find" stops at some directory
> with "fts_read: Not a directory":
>
> find . -exec md5 {} \; > /home/xxx/md5_out 2> /home/xxx/md5_err &
>
> tail /home/xxx/md5_err
> ...
> md5: ./.zfs/snapshot/20100323081201/Bazsi/Projects/Java Test
> Client/java_test_client/lib/xxx/weblogic.jar: Input/output error
> md5: ./.zfs/snapshot/20100323081201/@Cache (Bazsi)/BMWi
> SP/Publikationen/PDF-Broschâ–’ren/Nexxt.pdf: Input/output error
> find: fts_read: Not a directory
>
> What does this error mean? I cannot even "scan" the ZFS file system anymore?
> Is there any "fsck" for ZFS?
>
>
> Cheers,
> B.
>
> ----------------------------------------
>> From: zfsdisc...@orgdotuk.org.uk
>> To: zfs-discuss@opensolaris.org
>> Date: Mon, 7 Nov 2011 21:49:56 +0000
>> Subject: Re: [zfs-discuss] Remove corrupt files from snapshot
>>
>>> -----Original Message-----
>>> From: Edward Ned Harvey
>>> Sent: 04/11/2011 21:23
>>>
>>> You need to destroy the snapshot completely - But if you want
>>> to selectively
>>> delete from a snapshot, I think you can clone it, then
>>> promote the clone,
>>> then destroy the snapshot, then rm something from the clone and then
>>> snapshot the clone back to the original name, and then
>>> destroy the clone.
>>>
>>> Right?
>>
>> Not so fast! :-)
>>
>> If you promote this new clone, the current state / branch of your filesystem
>> becomes a clone instead, dependent on the snapshot.
>> Then if you try to destroy the snapshot, you'll fail, because it has a
>> dependent clone (your current fs!!!). If you continue
>> without realising the implications, and so try the 'destroy' again with
>> '-R', there goes the neighbourhood!
>>
>> I did this once, and was only saved by the fact that my cwd was in my
>> current filesystem, so couldn't be unmounted, and therefore
>> couldn't be removed! Phew!! Nice to learn something and only get singed
>> eyebrows, instead of losing a leg!
>>
>> hth Andy
>>
>>
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
