Converting ext3 to ext4 - results (Re: ext3 vs ext4)

[Bob Elzer]

This is informative, but I don't think the timing can be ruled accurate.

As I read your step, At first I thought tune2fs quit because it found
something wrong, and told you to run e2fsck first.

But further reading says, tune2fs makes a change, and then has e2fsck do all
the grunt work converting.

Your timings will be off, because the first e2fsck was doing all the hard
work, it was finding all the checksums and recalculating them for ext4, and
then writing them back to disk.

Thus you have all the I/O writes which adds a lot more time, then just
reads. Writing is slow compared to just reading, and it's not a big block of
writing, it lots of little writes.

It would have been nice to have an fsck before the tune2fs. 


-----Original Message-----
From: plug-discuss-bounces at lists.plug.phoenix.az.us
[mailto:plug-discuss-bounces at lists.plug.phoenix.az.us] On Behalf Of Charles
Jones
Sent: Friday, February 06, 2009 8:45 AM
To: Main PLUG discussion list
Subject: Converting ext3 to ext4 - results (Re: ext3 vs ext4)

Charles Jones wrote:
> I'm going to attempt a non-destructive conversion of a 2TB raid 
> parition from ext3 to ext4. I will post the results :)
Here's how it went. I did this on a system running Fedora Core 10:

This is the partition I'm converting:
# df -h /dev/sdc1
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdc1             1.8T  844G  991G  47% /raid2

I unmounted it, and ran the command (and used the "time" command to record
how long it took):
# time tune2fs -O extents,uninit_bg,dir_index /dev/sdc1 tune2fs 1.41.3
(12-Oct-2008)

Please run e2fsck on the filesystem.

real    0m0.390s
user    0m0.010s
sys     0m0.012s

Well that didn't take long at all.  Now for the fsck:
# fsck -pf /dev/sdc1
RAID2: Group descriptor 14903 checksum is invalid.  FIXED.
RAID2: Group descriptor 14904 checksum is invalid.  FIXED.
(a couple hundred of these quickly scrolled by) --^
RAID2: Adding dirhash hint to filesystem.

While it was running, I checked process listing and saw:
root     12393  0.0  0.0   3984   696 pts/2    S+   05:59   0:00 fsck 
-pf /dev/sdc1
root     12394 66.8 14.1 223272 219832 pts/2   D+   05:59   1:04 
fsck.ext3 -pf /dev/sdc1
This worreid me a bit at first, as I thought it should be running
/sbin/fsck.ext4 instead of fsck.ext3!

It's done!
RAID2: 350165/244203520 files (0.8% non-contiguous), 228806800/488382016
blocks
real    61m11.019s
user    0m0.002s
sys     0m0.011s

Now lets fsck again, to verify that fsck's under ext4 take less time: 
Before I run this second fsck I did notice that according to the drive
access lights, the raid was busy doing "something", even though the initial
fsck was complete.  What it is doing, I don't know - it's not defragging, as
there is a seperate e4defrag tool...Hmm. Oh well lets run another fsck and
see what happens:
# time fsck -pf /dev/sdc1
fsck 1.41.3 (12-Oct-2008)
RAID2: 350165/244203520 files (0.8% non-contiguous), 228806800/488382016
blocks
real    35m19.580s
user    1m48.430s
sys     0m41.541s

So fsck is a little over twice as fast now. I notice that after this fsck,
there is no drive activity like there was the first time, so let's do it one
more time:

fsck 1.41.3 (12-Oct-2008)
RAID2: 350165/244203520 files (0.8% non-contiguous), 228806800/488382016
blocks

real    34m51.145s
user    1m47.481s
sys     0m41.174s

About the same time, as the second run.  It looks like FC10 doesn't have the
e4defrag tool yet (I think requires new kernel).  When it is available I
will do a run of it and post the results as well.

# mount /dev/sdc1 /raid2
# df -h /raid2
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdc1             1.8T  844G  991G  47% /raid2

# mount |grep raid2
/dev/sdc1 on /raid2 type ext4 (rw)

-Charles



---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss