LMV Snapshots

[Ben Scott]

On 11/16/06, klussier at comcast.net <klussier at comcast.net> wrote:
> Nov 16 12:00:04 postal kernel: kjournald starting.  Commit interval 5 seconds
> Nov 16 12:00:04 postal kernel: EXT3 FS on dm-3, internal journal
> Nov 16 12:00:05 postal kernel: EXT3-fs: dm-3: 109 orphan inodes deleted
> Nov 16 12:00:05 postal kernel: EXT3-fs: recovery complete.
> Nov 16 12:00:05 postal kernel: EXT3-fs: mounted filesystem with ordered data mode.

  What that means is that inodes used for anonymous (unnamed) files
were freed on remount.

  Recall that *nix lets you create a file in the filesystem, hold it
open, unlink ("delete") the file from the directory, but then continue
doing I/O on the file until you close the file handle.  Anonymous
files are deleted  when they are closed.  This is commonly done with
temporary files, so that if the program is interrupted somehow, there
are no leftover temp files.

  Now, if the system itself is interrupted (e.g., crashes) while an
anonymous file is open, the inodes on disk will be marked allocated,
even though there are no file names linking to them.  In the days
before journalling filesystems, these would be caught in the fsck you
had to do anyway.  But on a journalling filesystem like ext3, where no
fsck is needed after a dirty mount, they would remain unclaimed, and
the system might eventually fill up with oprhaned inodes.

  So, ext3 maintains a list of all anonymous files.  If the filesystem
is remounted "dirty", it goes through the list and frees all the
inodes used by the anonymous files.  That's the message you're seeing.

> I don't have a whole lot of experience with LVM or snapshots. Does anyone have any thoughts on this?

  An LVM snapshot occurs at the device level, not the filesystem
level.  As far as ext3 is concerned, an LVM snapshot is identical to
powering the computer off at the moment of the snapshot.  Likewise,
most software is unaware of the LVM snapshot process, and may be in
the middle of writing to files, or have anonymous files open for
whatever reason.

 In short, anything that was busy at the moment of the snapshot is
left in an inconsistent state.

  ext3 thus has to do recovery of those anonymous files.  That's not
such a bad thing.  The bigger worry is that some data file somewhere
is in an inconsistent state, and no good for data recovery purposes.

  In the ideal world, software using the filesystem(s) in question
will be told to make their files consistent and hold new writes while
the LVM snapshot is created.

-- Ben