surprisingly successful restore from backup

Ben Pfaff pfaffben@msu.edu
10 Jul 2000 17:07:06 -0400


About three years ago I made a bad decision.  That is, when I
mke2fs'd my 3x4 GB RAID, I specified too-few inodes.  The result,
of course, is that I've been short on inodes for the last three
years.

Unfortunately there's no way to increase the number of inodes on
an existing drive.  Not even with an ext2 resize utility.  So
I've been stuck with it.

When I really ran out of inodes for good today[1] I finally got
up the courage today to wipe, re-mke2fs, and restore from DDS-3
tape backup.  It worked.  Perfectly, AFAICT.

However, it was pretty scary about 1 hour into it, because of an
undocumented (mis?)feature of tar.  I will explain what this is,
in case anyone else runs into the same issue in the future.

About 1 hour into the untar process, I started exploring the
restored directories, to make sure that everything was going as
planned.  However, it turned out that *every* directory was owned
by root/root with identical permissions, despite the fact that I
had specified the `--preserve' option to maintain ownership and
permissions.

This was not acceptable.  I grabbed the `tar' sources from the
net to have a look at what was going on, and found out by reading
`extract.c'.

As it turns out, in some circumstances GNU tar will set directory
ownership and permissions to default values, then, *after* it's
done extracting all the files from the archive, go back and set
their ownership and permissions the way they should be.  This is
because if it turned off directory write permissions, then it
couldn't extract files into that directory.

So after the 3-hour extraction process finished, `tar' went back
and fixed everything.  Yay!

I am astonished that it actually worked.  I was expecting to
spend the rest of the day rebuilding my home directory.

HTH,

Ben

[1] My first klugy "solution" was to create and mount a loopback
filesystem for some of my files, which in effect would increase
the number of inodes.  This quickly led me to the realization
that mounting a file with holes in it[2] as a loopback filesystem
is a good way to lock the kernel hard, requiring a reboot/fsck
cycle.

[2] i.e., as created by the following perl script:

open FOO, ">foo";
seek FOO, 1024 * 1024 * 1024 - 1024, 0;
print FOO "\0" x 1024;
close FOO;

which will create 1 GB file that only occupies about 1 kB of
actual disk space.