Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I started btrfs-convert for my ext4 partitioned hdd. I did a fsck first which was fine. So since it is running over 4 hours now (1.) I wonder if it will ever finish ? I read multiple articles (quickly) about the conversion but none stated a space requirement. But I guess there is some considering this article: https://oss.oracle.com/projects/btrfs/dist/documentation/btrfs-converter.html

So my HDD was using 99.0% of 1.82TB before I started. (2.) If it cannot finish is it save to cancel (CTRL+C) the prozess ?

iotop indicates still that btrfs-convert is reading with ~40MB/s from my hdd and top shows that one cpu core is fully loaded by btrfs-convert. (3.)What would be the wisest decision now?

Update: Meanwhile the conversion process has finished. It took almost 3 days. I must add that in between speeds dropped to ~0-10MB/s but 100% I/O load and CPU usage dropped accordingly down. This morning (after over 2 days running) the conversion process had only ~9h CPU time. All in all everything seems fine.

share|improve this question
    
Is this a / or non-Root file system? –  Terry Wang Feb 17 '13 at 23:28
    
It is a non-Root fs. –  kschurig Feb 18 '13 at 20:28
    
I just converted about 2TB of data on a 4TB drive (so 50% full) from ext4 to btrfs, and it took about 6 hours. Not sure if yours was so much slower because you were 99% full or if you were bandwidth or CPU limited (my intel core 2 CPU usage was at about 50% the whole time, so it might take a lot longer with a slower CPU). –  Fred Hamilton Jun 16 '14 at 6:17

3 Answers 3

btrfs-convert will create a snapshot (named ext2_saved) of the existing file system as a backup. It's hard to predict how much disk space the snapshot is going to take because btrfs is CoW...

I've converted a / for Oracle Linux 6.3 x86_64 before, it takes less than 10 mins because the file system is relatively small (data is stored on separate logical volumes). It was smooth, no issue.

In your case, the HDD has more than 1.8T data and little space left, no idea how long it is going to take (the snapshot may only use little space because the file system hasn't changed since the conversion). If iotop shows it's still running, leave it.

Only few people know what happens if you interrupt the convertion, try the btrfs mailing list;-)

Recommended readings:

https://blogs.oracle.com/wim/entry/btrfs_root_and_yum_update

5.4.6. Converting an Ext2, Ext3, or Ext4 File System to a Btrfs File System

share|improve this answer
    
Meanwhile the conversion process has finished. It took almost 3 days but everything seems fine. I am going to take a look at those articles anyway, thanks! –  kschurig Feb 18 '13 at 20:29
    
CoW? -------------- –  RobinJ Dec 9 '13 at 18:37
    
Never mind :) "Copy-on-write (sometimes referred to as "COW")" –  RobinJ Dec 9 '13 at 18:40
If it cannot finish is it save to cancel (CTRL+C) the process?

I just tried to convert an 8TB file system and btrfs-convert seems to have crashed, and btfsck gave a non-specific "Error", but rolling back with btrfs-convert -r only took a minute and everything seems fine with the old ext4 system.

So, aborting btrfs-convert seems to be relatively safe.

share|improve this answer
    
I just tried this, hitting Ctrl-C while btrfs-convert was running. It left the ext4 filesystem in a weird state. I could mount it, but not fsck it, because it said it was in use. In the end, I had to reboot to fsck it. –  Brian Minton Dec 9 '14 at 13:53

Just a data point really...

I just tried converting a 200G partition and using the btrfs-tools V4.0 and it failed - actually it seems it crashed - after reporting 'not enough free space' (partially overwriting the progress info).

# btrfs-convert -l trial /dev/trial/home
creating btrfs metadata.
not enough free space244027/    240502]
extent-tree.c:2628: btrfs_reserve_extent: Assertion `ret` failed.
btrfs-convert[0x41025d]
btrfs-convert[0x410281]
btrfs-convert(btrfs_reserve_extent+0x883)[0x41465e]
btrfs-convert(btrfs_alloc_free_block+0x63)[0x414715]
btrfs-convert(__btrfs_cow_block+0x101)[0x408edd]
btrfs-convert(btrfs_cow_block+0x89)[0x40948c]
btrfs-convert[0x409f57]
btrfs-convert[0x40a6a2]
btrfs-convert(btrfs_search_slot+0x7b3)[0x40b8a1]
btrfs-convert(btrfs_csum_file_block+0x26b)[0x417ee4]
btrfs-convert[0x42a062]
btrfs-convert[0x42a41d]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x147bd)[0x7f463c1f97bd]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x149ad)[0x7f463c1f99ad]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x154ab)[0x7f463c1fa4ab]
/lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_block_iterate2+0x2c [0x7f463c1faa7c]

fsck reported no problems and the filesystem still mounts:

# fsck -f /dev/trial/home
fsck from util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/trial-home: 240502/13107200 files (19.2% non-contiguous), 52237869/52428800 blocks

One interesting point is that the progress was reporting more than 100%, i.e 244027/240502. Perhaps someone could clarify what it was counting?

Anyway, the conclusion is that 744M out of 200G (99.7% used) is not enough free space!

FWIW, I would thing that btrfs-convert would get all the metadata in place before destroying (copying and overwriting) the 1Mb which indicated it's an EXT4 filesystem. Until it does that step, there's nothing to undo; it's just been writing in free space. Perhaps this could also be confirmed?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.