Converting ext3 to ext4 - results (Re: ext3 vs ext4)
Bob Elzer
bob.elzer at gmail.com
Fri Feb 6 11:42:06 MST 2009
In you timings, you say e2fsck now runs twice as fast. My impression was you
are using this to say ext4 is twice as fast now. Having a fsck timing before
you started would have shown us the real difference between fsck checks.
Thus I was pointing out, this would be false based on what each fsck was
actually doing at the time.
Knowing that it takes about an hour to convert 1TB of data on a 2TB drive,
is very informative.
Knowing, that tune2fs makes a little change and then fsck spits out a bunch
of errors, which would scare a lot of people, is also informative. It made
you nervous, but now the rest of us know not to panic when we see it.
And I presume your data is ok, or we would have heard something, so knowing
the conversion works is also informative.
Thanks
________________________________
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 11:16 AM
To: Main PLUG discussion list
Subject: Re: Converting ext3 to ext4 - results (Re: ext3 vs ext4)
Bob Elzer wrote:
This is informative, but I don't think the timing can be ruled
accurate.
Accurate as compared to what? I was just showing what it did on my system so
that people could get a *rough* idea of how long it would take to convert a
large partition.
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.
Yes the first fsck after the conversion is the long slow one.
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.
Timings will be off of what? I guess you mean if you have less or more data
it could take longer or shorter to convert (more inodes to muck around
with).
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
Yes. My RAID is hardware RAID5. For a single disk or striped array it
would probably go a bit faster.
It would have been nice to have an fsck before the tune2fs.
yeah I should have done that...I still have /raid1 to convert, which is
exactly the same size. I will do an fsck on that one first.
-Charles
-----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
---------------------------------------------------
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
--
___________________________
Charles R. Jones II
IT Team Lead/Senior Systems Engineer
Cisco Learning Institute IT Dept
work: 602.343.1534 cell: 602.738.9993
charles.jones at ciscolearning.org
More information about the PLUG-discuss
mailing list