Ext3 users - Apr 2005 - converting a floppy disk layout to partition layout

Hi all!

I have a slight problem: I have an external disk which contains one big
filesystem (like a floppy) type ext3 (If you ask why: blame udev or
maxtor, or me because I am stupid) which is approx 60% filled.

Now I want to have a partition table, ie a layout where the current
filesystem is the first partition, and the rest is as usual.

Is this possible withotu destroying the data?

Best wishes and thanks for any suggestions!

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining AT logic DOT at>             Universit? di
Siena
sip:preining at at43.tuwien.ac.at                             +43 (0)
59966-690018
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
LIMERIGG (vb.)
To jar one's leg as the result of the disappearance of a stair which
isn't there in the darkness.
			--- Douglas Adams, The Meaning of Liff

On Sun, Apr 10, 2005 at 03:26:12PM +0200, Norbert Preining
wrote:
> Hi all!
> 
> I have a slight problem: I have an external disk which contains one big
> filesystem (like a floppy) type ext3 (If you ask why: blame udev or
> maxtor, or me because I am stupid) which is approx 60% filled.
> 
> Now I want to have a partition table, ie a layout where the current
> filesystem is the first partition, and the rest is as usual.
> 
> Is this possible withotu destroying the data?
Theoretically?   Yes.

Is it going to be easy?  Unfortunatly, no one has written a tool to do
this (as far as I know) and doing it manually is going to be extremely
perlious.  What this theoretical tool would do (I don't recommend
trying to do this by hand!) is:

1) Shrink the filesystem just slightly using resize2fs so that there
is room for the partition table.

2) Move the filesystem down to make room for the partition table.
What is tricky about this:

	1) It's an overlapping move, so you have to start at the back
		of the disk and work forwards.
	2) You want some sort of program state checkpointing scheme so that
		if your system fails in the middle of the move, you don't
		end up with a completely toasted filesystem; it's critically
		important that the information about how far in the
		filesystem relocation you have been is recorded, so you can 
		restart it after a system crash.
	3) You need to know how far to move the filesystem, in order to make
		room for the partition table and start it at a
		suitable cylinder group boundary, so that partition
		table tools don't get confused/grumpy.

3) Create the partition table.

Another approach that might work is might be:

1)  Shrink the filesystem by 8 meg.

2)  Copy the first 4 megabyte chunk to the end of the filesystem.

3)  Add LVM2/device mapper partitioning information

4) Manually construct a new LVM2 logical partition which uses the new
   location of the first 4 meg chunk, and the location of the rest of the
   filesystem's 4 meg chunks.

If you're not willing to do a lot of development and testing, the best
way to do this is to buy or borrow a disk (disks are cheap!), and then
create the partition table on the new disk, shrink the filesystem
slightly using resize2fs, and then copy the partition over from the
old disk to the new disk.

						- Ted