Thread (13 messages) 13 messages, 6 authors, 2007-07-24

Re: [RFH] Partition table recovery

From: Indan Zupancic <hidden>
Date: 2007-07-22 21:23:24
Also in: linux-fsdevel, lkml

On Sun, July 22, 2007 18:28, Theodore Tso wrote:
On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
quoted
Sounds great, but it may be advisable to hook this into the partition
modification routines instead of mkfs/fsck.  Which would mean that the
partition manager could ask the kernel to instruct its fs subsystem to
update the backup partition table for each known fs-type that supports such
a feature.
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.

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.

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.
To be on the safe side, maybe also add a checksum, timestamp and
something identifying the disk the filesystem was created on.

Regards,

Indan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help