On Nov 11, 2013, at 5:36 PM, Edgar Fuß <[email protected]> wrote:
> Since I have been experiencing some mysterious file system corruption on a fs > that was fsck-clean before being mounted, I would like to periodically fsck > that fs while mounted. > The problem is that fs is 6T large. > > If I use an internal snapshot (fsck_ffs -X), the server stalls for about an > hour, then panics (wapbl_deregister_allocation: out of resources) and, upon > reboot, needs longer for replaying the journal than an fsck would take. > > If I use an external snapshot (fsck_ffs -x /somewhere/else), the snapshot > only > takes a few seconds, but fsck_ffs complains about unreferenced files, missing > blocks in the free list and bad summary information. I have tested both -x > and > -X on a smaller fs, and -X runs fine while -x complains. > > So why do internal and external snapshots behave so differently? Are they > just > two completely diffrent aproaches to the same problem or what's the reason > for > using what seems to be a totally different strategy when the backup file is > inside the fs itself? Two completely different approaches to get a stable view of a file system: - Internal (or -X) creates a copy of the file system and runs the equivalent of unmount on this copy. Therefore unlinked files disappear and bitmaps are consistent. - External (or -x) just saves original data to the backup before it gets overwritten. This snapshot is just a frozen image in time containing unreferenced but open files. Both snapshot types get created from a synced file system. As internal snapshots need much more I/O they are much slower. It helps a bit to use large (64k) file system block size (bigger blocks, less I/O). The snapshot type is determined from the location of the backup. > Is there any documentation on the subject? Not yet, sorry. -- J. Hannken-Illjes - [email protected] - TU Braunschweig (Germany)
