Convert your filesystem [hopefully] without data loss..

[UnixNut]

Hey, can I get some help with this?

I was trying to convert a 120GB data partition from xfs to ext2 using convertfs. But it seems to have hung at "Copying files".

Everything was going good until the last 20kb, at which point it didn't budge for hours. The filesystems look like this:

/dev/md0 112G 112G 20K 100% /tmp/convertfs/fs1root
/dev/loop7 111G 18G 88G 17% /tmp/convertfs/fs2root


now for whatever reason, its frozen. and under dmesg I get errors along the lines of:

Buffer I/O error on device loop7, logical block <block number> (e.g. 5263491, the numbers change constantly)
lost page write due to I/O error on loop7

Now I am worried, this does not sound good. So I ask, is it possible to abort the conversion and not lose my data? i can still see my data in fs1root, but I am currently worried that aborting the converstion will result in its loss. I have the important (work related) stuff backed up, but I still have about 100GB which I could not back up due to lack of backup space (hence why I am converting, rather then moving everything off, creating a new fs, and moving everything back).

Also, can anyone recommend a fix? I would like to convert this partition from xfs, but I would first like to know what could have caused this error, and how to fix it/prevent it from occuring again.

Any help appreciated!

EDIT:

I realised that what happened is that I ran out of space on the fs1root, which contains the fs2root loop image, so I ask, how much space is needed? I gave it 8G of free space (larger then any single file in the partition, which is what I thought the requirements were). How much space should I provide for a successful conversion???

[UnixNut]

ok, It has failed, but I seem to be able to recover the files (just mount the sparse loopback image created by the program, and mv the files back to the original parition).

In doing this, I noticed that the "mv" command first copies all the files in a directory, then removes them. I was under the impression that it works on a file by file basis (copy a file, then remove it), but rather it seems to work on a folder basis. This is what I believe caused the problem. My Ripped DVD collection has few folders, but many files. So in one folder there may have been up to 40GB of files. This means I would have needed to provide 40GB of free space for moving (which is a problem)

I will try to solve this by making lots of folders, and putting in 2/3 files each, making each "move" less then 2gb. Hopefully this will work, but I think the program should be modified so that files can be moved individualy, so that you need only as much free space as the biggest file, rather then the biggest folder.

I will post the results on this attempt here, for those who are interested.

[kriko]

Successfully converted 3 partitions from reiserfs 3 to ext3, total size 300GB. This program is great.

[UnixNut]

Belated... but a reply.

It worked, successfully converted XFS to ext2, 120GB RAID5 Disk array. The "making multiple folders" trick worked, by putting no more than 5 Video files in each folder, total space needed was about 4gb, so is ok now

Although this seems to be a limitation of the "mv" command more than the actual conversion, so thought maybe a /program script which would move on a file-by-file basis ( I thought of a wrapper around the "mv" command, but other ways are also possible) would not be a bad idea.