Message-ID: <46A46399.5090406@gmail.com>
Date:	Mon, 23 Jul 2007 10:15:21 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Theodore Tso <tytso@....edu>, linux-fsdevel@...r.kernel.org
CC:	Al Boldi <a1426z@...ab.com>, linux-raid@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFH] Partition table recovery

On 07/22/2007 06:28 PM, Theodore Tso wrote:

[ Al -- don't drop CCs please ]

> Well, let's think about this a bit.  What are the requirements?
> 
> 1) The partition manager should be able explicitly request that a new
> backup of the partition tables be stashed in each filesystem that has
> room for such a backup.  That way, when the user affirmatively makes a
> partition table change, it can get backed up in all of the right
> places automatically.

D-Bus? ;-)

> 2) The fsck program should *only* stash a backup of the partition
> table if there currently isn't one in the filesystem.  It may be that
> the partition table has been corrupted, and so merely doing an fsck
> should not transfer a current copy of the partition table to the
> filesystem-secpfic backup area.  It could be that the partition table
> was only partially recovered, and we don't want to overwrite the
> previously existing backups except on an explicit request from the
> system administrator.
> 
> 3) The mkfs program should automatically create a backup of the
> current partition table layout.  That way we get a backup in the newly
> created filesystem as soon as it is created.

On an integrated system like this, do you consider it acceptable to only do 
the MS-DOS partitions and not the other types that may be present _inside_ 
those partitions? (MINIX subpartitions, BSD slices, ...). I believe those 
should really also be done, but this would require keeping more information 
again.

> 4) The exact location of the backup may vary from filesystem to
> filesystem.  For ext2/3/4, bytes 512-1023 are always unused, and don't
> interfere with the boot sector at bytes 0-511, so that's the obvious
> location.  Other filesystems may have that location in use, and some
> other location might be a better place to store it.  Ideally it will
> be a well-known location, that isn't dependent on finding an inode
> table, or some such, but that may not be possible for all filesystems.
> 
> OK, so how about this as a solution that meets the above requirements?
> 
> /sbin/partbackup <device> [<fspart>]
> 
> 	Will scan <device> (i.e., /dev/hda, /dev/sdb, etc.) and create
> 	a 512 byte partition backup, using the format I've previously
> 	described.  If <fspart> is specified on the command line, it
> 	will use the blkid library to determine the filesystem type of
> 	<fspart>, and then attempt to execute
> 	/dev/partbackupfs.<fstype> to write the partition backup to
> 	<fspart>.  If <fspart> is '-', then it will write the 512 byte
> 	partition table to stdout.  If <fspart> is not specified on
> 	the command line, /sbin/partbackup will iterate over all
> 	partitions in <device>, use the blkid library to attempt to
> 	determine the correct filesystem type, and then execute 
> 	/sbin/partbackupfs.<fstype> if such a backup program exists.

I've cleaned up what I posted yesterday a bit and made it into the type of 
standalone-by-design program you suggest here (the version from yesterday 
required a -DTEST to be so). Not with the blkid bits though. Just dumps the 
sector to stdout (and a textual version to stderr if compiled with -DDEBUG).

I (very) briefly looked at blkid but unless I'm mistaken blkid needs device 
names? The documentation seems to be missing. When scanning the device for 
the partition table, we've built a list of partitions with offsets into the 
device and it would be nice if we could hand the fd and the offset off to 
something directly. If the program has to construct device names itself 
there's another truckload of pitfalls right there.

It wouldn't be hard to log minors as such, but you'd also need to be very 
sure you'd always do this in the same order as the kernel so that what I 
consider to be "/dev/sda2" is the same the kernel considers it to be. This 
is again rather fragile.

It might in fact make sense to just ask the kernel for the partitions on a 
device and not bother with scanning anything ourselves. Ie, just walk sysfs. 
Would you agree? This siginificantly reduces the risk of things getting out 
of sync, both scanning order and implementation.

The kernel doesn't currently store/export everything you'd want to store in 
a backup (as far as I'm aware, that is) but that could conceivably change. 
It would make things significantly less fragile.

Rene.

View attachment "partbackup.c" of type "text/plain" (4584 bytes)

Powered by blists - more mailing lists