On Tue, Nov 15, 2011 at 8:07 AM, <sbre...@hotmail.com> wrote:

> Thanks anyone for the help, finally I removed corrupt files from the
> "current view" of the file system and left the snapshots as they were. This
> way at least the incremental backup continues. (It is sad that snapshots
> are so rigid that even corruption is permanent. What more interesting is
> that, if snapshots are read only, how can they become corrupted?)

The snapshot is read-only, meaning users cannot modify the data in the
snapshots.  However, there's nothing to prevents random bit flips in the
underlying storage.  Maybe the physical harddrive has a bad block and
gmirror copied the bad data to both disks, which flipped a bit or two in
the file you are using to back the ZFS pool.  Since ZFS only see a single
device, it has no internal redundancy and can't fix the corrupted bits,
only report that it found a block where the on-disk checksum doesn't match
the computed checksum of the block.

This is why you need to let ZFS handle redundancy via mirror vdevs, raidz
vdevs, or (at the very least) copies=2 property on the ZFS filesystem.  If
there's redundancy in the pool, then ZFS can correct the corruption.

> Would it make sense to do "zfs scrub" regularly and have a report sent,
> i.e. once a day, so discrepancy would be noticed beforehand? Is there
> anything readily available in the Freebsd ZFS package for this?

Without any redundancy in the pool, all a scrub will do is let you know
there is corrupted data in the pool.  It can't fix it.  Neither can gmirror
below the pool fix it.  All you can do is delete the corrupted file and
restore that file from backups.

You really should get rid of the gmirror setup, dedicate the entire disks
to ZFS, and create a pool using a mirror vdev.

File-backed ZFS vdevs really should only be used for testing purposes.
Freddie Cash
zfs-discuss mailing list

Reply via email to