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

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Bob Elzer
Date:  
To: 'Main PLUG discussion list'
Subject: RE: Converting ext3 to ext4 - results (Re: ext3 vs ext4)
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:
[mailto:plug-discuss-bounces@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: 
    [mailto:plug-discuss-bounces@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 - 
    To subscribe, unsubscribe, or to change your mail settings:
    http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

    
    ---------------------------------------------------
    PLUG-discuss mailing list - 
    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



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