# Convert your filesystem [hopefully] without data loss..

## gfunkmonk

This will work for these filesystems:

minix xfs jfs reiserfs ext2 ext3

Warning:  This has caused at least 2 corrupt filesystmes (read posts below).  Always backup your data.  --pjp

OK, browse over to http://www.tux.org/pub/people/kent-robotti/looplinux/rip/

and download  the bootable cd ISO, and burn it to a cd.

Reboot with the cd in the drive, and type:

```

convertfs /dev/hdxx current_fs new_fs

```

After the conversion is done its probally a good idea to run fsck

```

The 'reiserfsck' program is used to check and repair

a linux reiserfs filesystem.

The 'xfs_repair' program is used to repair a linux

xfs filesystem.

The 'fsck.jfs' program is used to check and repair

a linux jfs filesystem.

The 'e2fsck' program is used to check and repair

a linux ext2 or ext3 filesystem.

```

So something like:

```

fsck.jfs /dev/hdxx

```

Next, mount the filesystem, 

```

mount /dev/hdxx /mnt/linux

```

and chroot into the filesystem

```

chroot /dev/hdxx /mnt/linux

```

and then proceede to edit /etc/fstab to use the correct filesystem, reboot and your done..

EDIT:  Added warning, and modified title to include "hopefully." --pjp

----------

## MoonWalker

Just a warning... This totally corrupted my 1.4 system when I tried to change fs from xfs to reiserfs, so a total reinstall remained the only choice.

HW facts was ABIT BG7 Mobo, P4 1.8, 512MB RAM, IBM 120GB HD devided in 3 primary and 1 extended and 9 partitions all together.

So it didn't work for me, but it may do for you... your choise.

----------

## nempo

Dosn't seem very reliable since it corrupted my ext3 root partition.

----------

## delta407

I think the moral of the story here is to have a backup before you attempt to do an in-place conversion between two very dissimilar filesystems.

----------

## pjp

Edited gfunkmonk's post to include a warning.  Sent a PM and mentioned he should feel free to change the warning, but that I thought one should be there.

----------

## aardvark

 *delta407 wrote:*   

> I think the moral of the story here is to have a backup before you attempt to do an in-place conversion between two very dissimilar filesystems.

 

And when you're making a backup anyway, you might as well reformat the file system after backing up and placing it back on the new/different filesytem. (of course edit the fstab accordingly) You wont need to dl. that looplinux ISO.

This could be how:

1. boot from install CD. an press enter till you have a prompt.

2. mount the fs you want to backup: (choose '??' and "gentoobakfs" to your own needs)

```
 mkdir /mnt/gentoobakfs

mount /dev/hd??  /mnt/gentoobakfs 
```

3. mount the place where the backup is to be written. (a partition with enough free space and a boot-cd-kernel-supported fs in the same manner as point 2. above)

4. cd to the mountpoint of point (2. )

5a. Backing up:  

```
 tar -cvzpf /mnt/place_to_put/your_backup.tar.gz *
```

(This will not pack any dot-files (hidden) in the 'root', but you normally don't have those.)

5b. Wait for it to complete (gzip is MUCH faster that bzip2 and only little larger)

6. unmount the partition you backed up:

```
 umount /mnt/gentoobakfs 
```

7. format the /dev/hd?? of point (2. ): 

```
mk(your_fs_of_choice) /dev/hd??
```

8. repeat point 2 and 4

9. Putting the backup back in place 

```
 tar -xvzpf /mnt/place_to_put/your_backup.tar.gz 
```

10. If necessary,

```
 nano -w /mnt/gentoobakfs/etc/fstab 
```

11. Unmount everything and you should be set after rebooting without CD.

----------

## guero61

Just thought I'd pass along that I just did the tarball conversion and it worked great, but some pointers I came up with before rebooting to the CD:

1.  Make sure you have a kernel in place that will handle both filesystems

2.  Don't forget to GRUB your /boot again; otherwise you'll get error 17.

Other than that, it was a flawless, lossless strategy; way to go!

----------

## ejwahl

Here's code that worked for me when I backed up root:

```
find / -path /mnt -prune -o -path /dev -prune -o -path /proc -prune -o -print | cpio -pvdm /home/user/backup
```

This copies everything in / except for /mnt, /dev and /proc to /home/user/backup.  

HTH

----------

## co-D

This is what i made to make my backups easier, i'm a novice at scripting so revise it if you wish to use it, but i've backed up my system from it before when i've felt like reformatting root as a different filesystem.Just boot from the gentoo livecd (or any other bootable disk for that matter) and extract the tar.gz's to the new root  and boot partitions.

You might have to reinstall your boot loader, but for some reason last time i did this it just worked.

```

#!/bin/bash

archive='/mnt/xfs/backup'

directories='bin boot dev etc home lib mnt opt root sbin sys tmp usr var'

Date=`date +%F`

command='tar -cvzpf'

exclude='/usr/portage/distfiles/* /var/tmp/portage/* /mnt/*/*'

excludefile=$archive/$Date/excluded 

if [ ! -d $archive/$Date ]

  then

     mkdir $archive/$Date 

  fi

if [ -e $archive/$Date/excluded ]

  then

     rm -f $archive/$Date/excluded

  fi

  

for f in ${exclude}

  do

   echo ${f} >> $archive/$Date/excluded

  done

 

echo -en '\E[40;37m'"\033[1m"Excluding Files:"

`cat $excludefile`\033[0m"   # White

   tput sgr0

echo "" 

for d in ${directories}

do

  if [ -e $archive/$Date/${d}.tar.gz ]

   then

   

   echo ""

   echo -en '\E[40;36m'"\033[1m"Archive exists, skipping "$archive/$Date/${d}.tar.gz"..."\033[0m"   # Cyan

   tput sgr0

   echo ""

else

   echo ""

   echo -en '\E[40;32m'"\033[1m"Creating "$archive/$Date/${d}.tar.gz"..."\033[0m"   # Green

   tput sgr0

   echo ""

if [ $d == boot ]

   then

   mount /boot

   $command  $archive/$Date/${d}.tar.gz /${d} --exclude-from=$excludefile

   umount /boot

   else

   $command  $archive/$Date/${d}.tar.gz /${d} --exclude-from=$excludefile

   fi

fi

done

echo -en '\E[40;31m'"\033[1m

"%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  NOTE  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%"

"\ \ \ \ \ \ \ \ create /proc and /sys directories in new system \ \ "

"%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  NOTE  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%"\033[0m"   # Red

echo ""

   tput sgr0

```

----------

## Trellph

I had me some fun with this.  I thought like most applications that did this it would load itself into memory.  I found out I was wrong when /bin was erased and it errored out

not to worry, /bin is easy to replace.

so I boot to a cd and do it, thinking that it loaded itself into memory but not mv rm cp and whatnot.

It made the image just fine, but then it stopped because it didn't load it's 2 other counterparts into memory.  oops.

To resolv this I mounted the image to another dir, mv'd all the files back, and use a tmpfs in ram to copy over the convertfs files to from /sbin and it worked finally ;p

sure takes a long time for it to mv over to itself 12 gigs of data tho.

----------

## Deathwing00

The command covertfs does not exist any more in the RIP CD... so this Doc is OBSOLETE/NEEDS RENEWAL.

OK, I have tweaked around and finally got how to do it:

--- Root Partition to be converted ---

1. If the partition you want to convert is the root one, then boot into your system.

2. # emerge convertfs

3. reboot the system with the gentoo LiveCD

4. mount your root partition (the one to be converted)

5. copy the following files from /mnt/gentoo/sbin/ to /sbin/:

     - convertfs

     - convertfs_dumb

     - devclone

     - devremap

     - prepindex

6. unmount the partition

7. (this one is important!) # cd /sbin/ 

8. # convertfs /dev/hdxY current_fs target_fs

9. wait until it ends  :Smile: 

--- Non-root partition to be converted ---

1. If the partition you want to conver is not the root one, then it's easier; boot into your system.

2. # emerge convertfs

3. make sure that the partition is not mounted

4. # convertfs /dev/hdxY current_fs target_fs

5. wait until it ends  :Smile: 

Have fun!

----------

## thrasher6670

I have copied this article to

http://gentoo-wiki.com/HOWTO_Convert_Filesystems

I included Deathwing00's changes ... sorta  :Smile: 

If anyone things anything needs changing, go for it

----------

## Deathwing00

 *thrasher6670 wrote:*   

> I have copied this article to
> 
> http://gentoo-wiki.com/HOWTO_Convert_Filesystems
> 
> I included Deathwing00's changes ... sorta 
> ...

 

Nice one indeed  :Smile: 

----------

## ZeroDivide

I'm not sure if it's just my setup, but convertfs is EXTREMELY slow.

It's taking about 3 1/2 hours to convert 1 gig of data from reiserfs to xfs.

I have DMA enabled and 1/3 of the partition is free space so I dont think its a problem with my drive. 

Anyway, just thought I would post this to let people know how slow it can be before they embark on their long conversion journey  :Smile: 

----------

## Deathwing00

This is very strange... it didn't take so much time for me.

----------

## ZeroDivide

It looks like i jumped the gun a little bit, converting 15GB only took 6 hours.   :Embarassed: 

----------

## asph

i think that "How to convert your filesystem and lose all your data" would be more accurate.. i run it to convert from reiserfs to xfs, and after 2 secons it output "mv: comand not found" and stopped working.. after rebooting i had lost config files, binaries and a bunch of files so it won't boot!

of course i did a backup before so i have my system back again, but i don't understand how this tool is in portage, it totally sucks. You can't release a tool this dangerous if you are not 100% sure it works! I know they say that "warning, this can delete your data blah blah", but then just don't put it on portage.

----------

## Moloch

Sounds like you ran it from your current live system. Idealy you want to run it from a boot CD so you aren't attempting to convert files/partitions that are in use.

----------

## Conan

I just tried doing this... and when i try to copy convertfs from /mnt/gentoo/sbin/ to /sbin, it tells me that /sbin/ is a read only file system, is there some way to fix this?

----------

## bigredgiant1

I think a better way to do this if you had the space would be to copy everything over to a second drive, make the new filesystems on your partitions, and copy everything back over, like so:

```

<boot a live cd and mount all your partitions/drives>

# chroot /mnt/gentoo

# mount /dev/hdb1 /mnt/tmp_drive

# mkdir /mnt/tmp_drive/gentoo

# cd /

# find . -print | cpio -pamd /mnt/tmp_drive/gentoo

# umount /mnt/tmp_drive/gentoo

# exit

<this will probably take at least 10 or 15 minutes>

# umount /dev/hda3 /dev/hda5 ...

<I use reiserfs here but use whatever filesystem you desire>

# mkreiserfs /dev/hda3

# mkreiserfs /dev/hda5

<continue for all of your partitions...>

# mount /dev/hdb1 /mnt/tmp_drive

# mount /dev/hda3 /mnt/gentoo

# mount /dev/hda5 /mnt/gentoo/var

<continue as needed>

# cd /mnt/tmp_drive/gentoo

# find . -print | cpio -pamd /mnt/gentoo

<Reboot and you're done>
```

----------

## rvkasper

Hi all,

I decided to convert a 200 gig partition from reiserfs to ext2 so that it will work when I move my Fedora Core 2 OS over to FreeBSD - to facilitate this I compiled convertfs from source and am running it from my current OS installation.  4 days later it is still going, running devremap - it is currently here:

Relocating block group at 2899145...

Any thoughts on how far it has left to go - is there some output from a command (like HDParm) that would help me figure that out?

Also, would booting from this gentoo livecd speed things up at all?  This is not my root partition I am converting - simplay a data partition - my root partition is ext3.

- Ryan

----------

## frostschutz

Two issues with convertfs:

1. You need a lot of free space on the partition you want to convert.

convertfs uses 'mv' to move all directories (including subdirs and files) from the root tree to the image. When moving directories, 'mv' will delete the source files only after the whole thing was copied, so you need at least as much free space as the space consumed by the biggest directory (including subdirs and files) on your partition. You can find out that size using 'du'.

2. Relocation of blocks is damn slow.

After the image was completely created, you have your old filesystem with a single file in it (image of the new filesystem), and in that image there are all your files. Now, for the image to replace your original filesystem, convertfs has to move the blocks of the image file onto the appropriate positions on your hard disk.

Think of your partition now as a really fragmented system and you're trying to use Windows defrag to solve the system - every block of every single file has to be moved to a different location (and that location might already be occupied by other blocks).

So in short, there is a lot of shuffling around involved, and in the current convertfs, this is not solved very efficiently, so depending on how much block relocations have to be done, this will take AGES. And I really mean AGES - I'm trying to convertfs a 80GB partition from ext3 to xfs right now and after one day, the progress is at 1GB out of 80GB. So with any luck I only have to wait 79 more days for it to get finished.

The problem lies within devremap.c, in the function find_cross_block, which wastes a lot of time trying to find the correct physp location. The CPU has to do an awful lot of work, disk activity is extremely low (looks like one block write every 20 seconds).

I don't fully understand what devremap.c is trying to do here (there does not seem to be any documentation, grrr), but this can be done faster in any case.

----------

## frostschutz

filed a bug report for this: sys-fs/convertfs eats 100% CPU for days on end

comments are welcome...

EDIT:

attached a patch to the bug report, which fixed the 100% CPU / very slow progress problem for me. conversion of 80GB partiton ext3 -> xfs succeeded  :Smile: . Still, this is highly dangerous software and it has other bugs as well. But if you're already stuck in the 'relocating blocks' part of convertfs, the patch might help you. It's reasonably safe to ctrl+c out of the relocating (while there is nothing being written on the hard disk) and resume with the patched program.

Oh, and make sure you compile it with -march=your_cpu_type and -O2. It'll be really slow otherwise. And don't use -O3, for some reason that slows down the process as well.

----------

## dj015

For those people that, like me, found this forum too late:

1. In the "Relocating block group at X" messages, X is the filesystem block number, not a kilobyte number. So if you have a filesystem with 4kB blocks, multiply X by 4 to get the number of kilobytes.

2. The reason it is slow is the poor block relocation algorithm (you can't code a triply nested loop, and then use "gcc -O3" to make it fast: compilers never reduce the algorithm's order of complexity...).

3. convertfs is very robust - it survived about 5 Ctrl+C's and a power failure.

4. The "very ugly patch" works like a charm. It stripped down the conversion time for my 120 GB filesystem from 11 days to 6 hours. I did e2fsck afterwards and it found no errors, my files were all there, and I opened a couple of them and they were fine. Thank you Andreas!

5. I am never using it again.

----------

## dajja

I have recently successfully converted an ext3 partition to reiserfs (no corruption reported by fsck)   :Very Happy: 

But I am (still) somewhat suspicious if it will work in the long run (I will probably notice if it doesn't  :Wink: )---is fsck completely reliable in reporting a possible corruption/error in a filesystem? Are there other tools to consider?

----------

## 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!  :Smile: 

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  :Smile: 

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.

----------

