andrew-ubuntu-devel at pileofstuff.org
Sun Aug 17 21:09:30 UTC 2008
I've been trying out a script (attached) for the last few days, that
does something similar to the idea in my previous comment. It's a shell
script that can be put in cron.daily and/or called from an @reboot cron
job. The script checks each of your LVM-based filesystems in turn, and
won't start a new check if it's been going for more than 10 minutes.
The short version of the story is that fsck'ing a snapshot of a live
filesystem is possible, but we might want to get at least a little input
from LVM or FS developers first.
The main problem with this script is that it trips over on temporary
files. It's common for programs (via mkstemp(), I think) to create a
temporary file, open it, then delete it. The inode that was previously
associated with the file continues to exist so long as a file descriptor
to it remains open, but when a snapshot of the filesystem is created,
the inodes are never removed, so they become orphans. fsck notices this
minor problem in the snapshot and flags the filesystem as needing to be
Steps to repeat this problem:
$ sudo /etc/init.d/mysql start # creates temporary files on my system
$ sudo lvcreate -L1024M -s /dev/your-volgroup/your-root-device
$ sudo fsck -v -n -f /dev/your-volgroup/lvol0
$ sudo lvremove /dev/your-volgroup/lvol0
fsck should complain about orphaned files. I get this:
$ sudo fsck -v -n -f /dev/nautilus/lvol0
fsck 1.40.8 (13-Mar-2008)
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 180229 has zero dtime. Fix? no
Inodes that were part of a corrupted orphan linked list found. Fix? no
Inode 180230 was part of the orphaned inode list. IGNORED.
Inode 180231 was part of the orphaned inode list. IGNORED.
Inode 180232 was part of the orphaned inode list. IGNORED.
Inode 180233 was part of the orphaned inode list. IGNORED.
Inode 180251 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -(180229--180233) -180251
root: ********** WARNING: Filesystem still has errors **********
23381 inodes used (8.92%)
518 non-contiguous inodes (2.2%)
# of inodes with ind/dind/tind blocks: 2563/15/0
211424 blocks used (40.33%)
0 bad blocks
1 large file
13390 regular files
1258 character device files
4553 block device files
1216 symbolic links (1137 fast symbolic links)
To my untrained eye, it looks like this could be argued to be a bug in
ext2 or LVM (because they're not deleting inodes properly), or a bug in
fsck (because it doesn't have an "errors remain, but who cares?" return
code). Alternatively, it could be argued that the fsck script I've
written should parse the output of fsck and decide which filesystem
errors are really important.
I've gone as far as I can go with this idea - if someone with more of a
clue is interested, could you suggest the best way of solving this issue?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fsck (DO NOT USE)
More information about the Ubuntu-devel-discuss