Troubleshooting mount problems

If you are unable to mount the filesystem directly, you might be able to recover the snapshot using the same methods you would use after a system crash.  In some cases, you can simply fsck the filesystem.  Again, you have to force the filesystem type.  You might think you can do this by specifying the filesystem type to the fsck command in the same way as we did with 'mount':

fsck -t ext3 /dev/vg/fs-snap

However, again there is a problem with DRBD backing devices - the above command reports:

fsck from util-linux 2.22.2
fsck: fsck.drbd: not found
fsck: error 2 while executing fsck.drbd for /dev/mapper/vg-fs--snap

Even though we try to specify the filesystem type on the command-line the 'fsck' command reads it from the device anyway.  Fortunately, the 'fsck' command is actually a wrapper to the various filesystem specific fsck.<type> commands.  We can bypass the automatic type detection by directly calling the filesystem type command fsck.<type>.  So for an ext3 filesystem:

fsck.ext3 /dev/vg/fs-snap
e2fsck 1.42 (29-Nov-2011)
/dev/vg/fs-snap: clean, 304173/655360 files, 815558/2621351 blocks

It is a good idea to force a full filesystem check, unless you're sure the filesystem is intact.  To do this, specify the force flag '-f' to the command:

fsck.ext3 -f /dev/vg/fs-snap
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg/fs-snap: 304173/655360 files (0.1% non-contiguous), 815558/2621351 blocks

If you're able to get the filesystem cleaned up, you should be able to mount it as described above.

If you're not able to get the filesystem cleaned up, perhaps try another snapshot.  With active systems, it is all about the timing, and a another snapshot might work in cases where a previous snapshot failed.