command to recreate an FS?

[Bodo Thiesen]

* Morty <morty+redhat at frakir.org> hat geschrieben:

>* On Sun, Jun 07, 2009 at 12:43:04AM -0700, Christian Kujau wrote:
>>* On Wed, 3 Jun 2009, Morty wrote:
>>> Is there a lightweight command to recreate an ext2/ext3/ext4 FS with
>>> original options,

> Even if no options were specified, some distros use UUID as the basis
> for FS mounts. [...]  That's great if disks move around, but not so good if I
> upgrade from one disk to another.  [...]

> Speaking of which, is there a way to set the directory hash seed?
> tune2fs -l will show me the current hash seed, but I don't see an
> option in mke2fs or tune2fs to set it.

If you only intend on moving a file system from one disk to another, I'd
suggest the following procedure:

1.) Install the new disk leaving the old installed.
2.) Make any partitioning necessary.
3.) Remount the file system to be moved r/o if it's mounted r/w currently
    (»init S« or »init 1« and »lsof« is your friend ;)
4.) dd if=old_partition of=new_partition
5.) resize2fs new_partition
6.) install lilo/grub on the new disk
7.) shutdown, remove the old disk, reboot

This approach should leave the uuid and directory hash seed unchanged.

If you however intend to recreate the file system after severe data loss
without resizing of the file system itself, then you could do this:

Save the old super block (the best would be to do this BEFORE you loose
the data ;)

You can use the following command for that:

dd if=partition of=filename4superblock bs=1024 skip=1 count=1

After you have recreated the file system with the same arguments to mke2fs,
you should be able to restore the old super block using this command:

dd if=filename4superblock of=partition bs=1024 seek=1 count=1

After that, you will have to run e2fsck -fD, to update the copies of the
super block and to recreate the directory hashes for root and lost+found.

Now you can fill up the file system with the most recent backup.

Regards, Bodo

PS: If you're gonna write your Perl script to store the bare minimum data,
I'd suggest you store a) the (first) super block, b) the group descriptor
table c) the first three blocks (one block is 512 byte as we all know) of
the inode table. To save space, just compress the data using lzma or some
other compressor. Writing this information to the right places of an empty
file system should be enough to recreate the filesystem, however, e2fsck
would be neccessarry then too, because you will loose the contents of the
root and lost+found directory by this approach which have to be recreated.
Zeroing out the device before writing back this data would be a good
thing, too.