[PLUG] Filesystem issues

[Elliott Mitchell]

>From: John Jason Jordan <johnxj at comcast.net>
> The mystery is why, when booting the new Dapper, it showed all my old
> files. There are two possibilities, as far as I can figure. 1) The new
> Dapper mounted my Breezy /dev/hda2 somewhere, and the blond boy got
> confused and wandered into it by mistake, thus thinking Dapper had been
> installed over the old Breezy installation or, 2) the messed up inodes
> were the culprit and I'm not as blond as I seem. It would make me feel
> much better if it turns out to be (2). I offer only one fact in support
> of (2): I booted all five possibilities (two Dapper, three Breezy) and
> each time I got Dapper, and I'm pretty sure each time all my files were
> there, and each time I got the "fsck needed" warning and used Ctrl-D to
> ignore it and boot anyway. It was AFTER I finally let it fix the
> filesystem problems, which it said were messed up inodes, that booting
> one of the Breezy options worked properly. I haven't tried anything since.

I'm sorry, but it very definitely sounds like #1. Time to queue the
jokes. As I think you've figured out, the Dapper Drake install noticed
the existing filesystem and mounted it. In general a reasonable and
pretty harmless thing to do, though it sounds like it confused you.

> Besides getting messed up, what do inodes do?

They're a specific piece of on-disk structure. In traditional filesystems
you get two types of blocks; data blocks and blocks of inodes. Data
blocks simply hold actual file data, simple and boring. inodes are the
"heads" of files, they contain permissions information and point to
blocks of data, they also hold a reference counter. A directory is an
inode where the data blocks contain filenames and pointers to inodes. Due
to the reference counter, multiple directories can contain links to the
same inode and the reference counter tracks the number of links (this is
what `ln` without -s does). For really large files the inode has an
indirection pointer, which is simply a data block with pointers to other
data blocks (with the largest files on a traditional UFS filesystem,
there could be 3 levels of indirection).

So literally an inode is pretty well a single file.

A wrong reference count means the reference counter on the inode had a
number that was different from the number of links that `fsck` found. If
the reference counter was too low, if one link was removed the system
might try deleting the data blocks while there was still a legitimate
pointer to the file. If the reference counter was too high, the system
might of removed the last link, but never marked the data blocks as
unused. On ext2 inodes also have a marker indicating whether they're a
file, or have been deleted; so if fsck finds an inode that is marked as
a file, but no links that is an unreferenced inode.

In traditional filesystems, inodes are allocated in distinct areas of the
disk, separate from where data blocks are located. This makes allocation
simpler, disk checks simpler and works pretty well. Some filesystems,
such as ReiserFS simply allocate inodes out of the pool of data blocks.

One interesting bug report was a case of a disk recovery firm storing an
image of a ReiserFS on top of a ReiserFS filesystem. They had a crash and
had to run a full check with fsck. fsck found the contents of the
filesystem, but it also found something that looked like part of a valid
ReiserFS filesystem inside the data blocks of what was a file. The
result was it merge the FS-image with the parent filesystem. Afterwords
they added per-FS magic numbers to the inode blocks. An interesting case
of the unexpected happening.


>From: John Jason Jordan <johnxj at comcast.net>
> 1) I googled and man-paged on fsck and can't find a way to give a
> command that it should be run on the next boot before the filesystem is
> mounted. I did try to run it while the system was mounted, but it gave
> me dire warnings, so I canceled. Maybe I missed the option that I need.
> I can't give the command during boot because there is no command line
> then. In Windows the GUI has an option to clean up the disk or
> something (never needed it), and if you click on Yes it announces it
> will be run on the next boot. What is the Linux way to do this? Or is
> there a better way?

The simplest is to do `touch /forcefsck`. Nearly all distributions this
will pass "-f" to fsck on the next boot, forcing fsck to look at the
filesystems even though they appear to be clean (unmounted properly).

The hard-core hacker way is to pass "init=/bin/bash" to the kernel. This
causes the kernel to run the shell instead of init, and you get a true
single-process system. From here you run `fsck` and clear out any damage
that has been done. If you need to remove or change anything on the
root filesystem you do `mount -n / -o rw,remount` (and a
`mount -n / -o ro,remount` when done!).


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/