Disk images, zfs scrub and dealing with errors
If scrub reveals an error in the part of the dataset that stores a sparse disk image:
- it may be difficult to identify the affected file(s) within the image.
If scrub reveals an error in the part of the dataset that stores a sparse bundle disk image:
- we might identify an affected band, but it may be difficult to identify the affected file(s) within that band
- if something other than a band is affected, difficulties may be greater.
Example
Echoed from viewtopic.php?p=1256#p1256
- Code: Select all
sh-3.2$ sudo zpool status -xv -T d
Sat 22 Sep 07:56:58 2012
pool: blocky-OS
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
scan: scrub repaired 1.62Mi in 5h22m with 50 errors on Sat Sep 22 07:06:38 2012
config:
NAME STATE READ WRITE CKSUM
blocky-OS ONLINE 0 0 50
GPTE_31EC193D-5063-4C3C-A3F4-B09A8CBB3C6D ONLINE 0 0 217 at disk5s2
GPTE_EF222F60-36F0-4B9C-86C1-0FB57C2000BE ONLINE 0 0 0 at disk8s1
errors: Permanent errors have been detected in the following files:
blocky-OS:/macbookpro08-centrim.sparsebundle/bands/6cce
blocky-OS:/macbookpro08-centrim.sparsebundle/bands/6ccf
sh-3.2$ clear
… and zoom in to the potential for problems:
- Code: Select all
blocky-OS:/macbookpro08-centrim.sparsebundle/bands/6cce
blocky-OS:/macbookpro08-centrim.sparsebundle/bands/6ccf
If you encounter that type of situation, with bands of a sparse bundle disk image that provides a JHFS+ volume, how will you deal with likelihood of corresponding errors on the JHFS+ volume?
As fsck_hfs may not find those errors, you could:
- abandon the current disk image (abandon all current files on the JHFS+ volume)
- mount a snapshot to restore an older version of the disk image.
To minimise the possibility of error
Consider storing your disk images (nothing else) on a child file system, and set copies=2 or copies=3 for that file system.