# Need ext3-to-ext4 conversion on / partition adviceSOLVED

## wrc1944

I have one last ext3 Gentoo install on sda11 (~amd64, current with all updates,and 4.3.3 kernel) which I wish to convert to ext4 without doing a reformat/re-install. 

Current grub on sda11 is gentoo current legacy version (I boot this distro testing box from sda1 with grub2 managing all 7 distros currently installed, including this sda11 gentoo), but I could first update to grub2 on sda11 if I might run into problems with ext4 booting with legacy grub. All 7 distros are installed completely on their own single partition, and share a swap partition.

First, on sda11 Gentoo change the fstab / line type to ext4, and add the command line parameter "rootfstype=ext4" to the kernel command line in the GRUB config

After insuring kernel ext4 options are enabled on the sda11 gentoo, either boot from live cd, or one of the another Linux ext4 distros on another partition, and proceed to work as follows on sda11:

1. Run tune2fs -O extents,uninit_bg,dir_index /dev/sda11

2. Run fsck -f -p /dev/sda11 as root

3. reboot

From the Arch Linux wiki page on Converting_ext2.2Fext3_partitions_to_ext4:

Recommended: mount the partition and run e4defrag -c -v /dev/sdxX as root to enable the ext4 features by re-writing all files.

I plan on doing the gcc-5.3.0 upgrade (already did gcc-5.3.0 on two other Gentoo installs), and all the rebuilding involved, so wouldn't that rewrite everything on sda11 and enable extents on the newly converted ext4 FS, so i could skip the e4defrag run?

Have I missed anything in my proposed procedure, and will the current sda11 legacy grub version handle ext4 booting OK? Any other fsck options I need to enable?  Any other last minute advice to avoid potential problems?

----------

## khayyam

wrc1944 ...

looks fine ... as far as e4defrag is concerned its not necessary, though, as the name suggests, running it will 'defragment' the filesystem (which may be a plus dependent on the age of the install, and level of fragmentation).

```
# tune2fs -l /dev/sda11 | grep created
```

Once converted to ext4 you could run 'e4defrag -c /dev/sda11' and get a report on the level of fragmentation ... and so perhaps decide on whether to run e4defrag or not.

best ... khay

----------

## wrc1944

Thanks khayyam,

All went well, and after rebooting back into the sda11 Gentoo, I did run e4defrag -c -v /dev/sda11, and got:

```
Total/best extents                             1126007/707576

 Average size per extent                        18 KB

 Fragmentation score                            64

 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]

 This device (/dev/sda11) needs defragmentation.

 Done.
```

Since I had a score of 64, I then ran e4defrag /dev/sda11 and got:

```
[797451/797452]/tmp/runtime-wrc/KSMserver__0:   100%    [ OK ]

        Success:                        [ 638656/797452 ]

        Failure:                        [ 158796/797452 ]

gentoo-amd64 wrc #
```

Then checked again with -c, and got:

```
Total/best extents                             1125080/707646

 Average size per extent                        20 KB

 Fragmentation score                            58

 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]

 This device (/dev/sda11) needs defragmentation.

 Done.
```

Not much improvement,  The next run only got to:

```
Total/best extents                             1125300/707795

 Average size per extent                        21 KB

 Fragmentation score                            54

 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]

 This device (/dev/sda11) does not need defragmentation.

 Done.
```

Doesn't seem to be making much progress, at least compared to what I recall windows defragging was like, but maybe it doesn't need to.   :Cool: 

No matter- I just wanted ext4 and extents and gcc-5.3.0 on this one last Gentoo ext3 Install.

Anyway, I'm now halfway finished with my gcc-5.3.0 rebuilding run of emerge -De @system, and will then finish up the rest of @world with the very nice commands Zentoo gives us at:  https://forums.gentoo.org/viewtopic-t-1035298.html.  :Very Happy: 

----------

## khayyam

 *wrc1944 wrote:*   

> Doesn't seem to be making much progress, at least compared to what I recall windows defragging was like, but maybe it doesn't need to.  8)

 

wrc1944 ... this may be due to fact that its a converted ext3, I'm really not sure. Compare to mine, which has been ext4 from the outset, and never defragged:

```
# tune2fs -l /dev/mapper/vg-root | grep created

Filesystem created:   Mon Apr  8 07:08:22 2013

# e4defrag -c /dev/mapper/vg-root | awk -v RS="\n\n" '/.Total/'

 Total/best extents                             123176/122334

 Average size per extent                        31 KB

 Fragmentation score                            1

 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]

 This device (/dev/mapper/vg-root) does not need defragmentation.

 Done.
```

I run the same on the other lv's and pretty much the same, all score about 1.

best ... khay

----------

## wrc1944

Interesting. 

That old ext3 partition was about 4-5 years old, so probably it was a bit fragmented. 

I have another Gentoo ~amd64 partition on this disk I just installed about a month ago, and as soon as I can finish up this converted partition rebuild, I'll reboot to the other Gentoo and run e4defrag and compare.  I'm thinking the fragmentation score will be closer to yours. Guess I'll run e4defrag on all my linux ext4 systems and see what's up.  I have noticed over the many years of running gentoo that no matter how lean and depcleaned I keep the system, it gradually over time appears to run slower and slower. Of course nothing near like what a windows OS does, but it is noticeable.  Thanks again for the feedback.

----------

## s4e8

ext4 extents require larger inode-size, it's better backup and re-format.

----------

## mv

 *s4e8 wrote:*   

> ext4 extents require larger inode-size

 

Yes, one should use additionally tune2fs -I 256 .... (followed by fsck).

 *Quote:*   

> it's better backup and re-format.

 

There might always be bugs, of course, but normally the tune2fs followed by fsck should not cause any problems. I did it with many file systems years ago. Of course, having a backup is never wrong and might save you in case of bugs.

----------

## wrc1944

s4e8,

Thanks for the tip- made me think and do some more research.  I get your point now, however, I just ran dumpe2fs, and it shows the inode size as 256 with "resize_inode extents" now enabled on the converted ext3 to ext4 partition.  

As I understood it, 256 is the correct inode size for ext4, and 128 for ext3. (wish I'd have checked the ext3 inode size before I moved it to ext4)

So, I'm wondering how my old ext3 could now have all the ext4 features like you mention about the inode size without a reformat, which obviously would have destroyed my standing ~amd64 Gentoo install, which of course it has not.  I've also upgraded to gcc-5-3.0, and rebuild the entire Gentoo install, without any problems. 

In other words, it appears either my old ext3 somehow already had inodes of 256, or moving to ext4 increased inode size from 128 to 256 (and enabled extents) without needing a reformat.  Am I just missing something- I'm certainly no expert on this stuff?  Now I wonder if increasing the inode size on an existing partition with a functional OS does actually require a reformat, and thus an OS reinstall.

```
gentoo-amd64 wrc # dumpe2fs -h /dev/sda11

dumpe2fs 1.42.13 (17-May-2015)

Filesystem volume name:   <none>

Last mounted on:          /

Filesystem UUID:          e4743c86-8b6a-4e69-a063-4a7ae6358cc7

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file uninit_bg

Filesystem flags:         signed_directory_hash 

Default mount options:    journal_data_writeback

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              2662400

Block count:              10648320

Reserved block count:     532416

Free blocks:              5487779

Free inodes:              1865053

First block:              0

Block size:               4096

Fragment size:            4096

Reserved GDT blocks:      1021

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         8192

Inode blocks per group:   512

Filesystem created:       Mon May 30 12:50:05 2011

Last mount time:          Thu Jan 14 12:20:45 2016

Last write time:          Thu Jan 14 12:20:40 2016

Mount count:              2

Maximum mount count:      23

Last checked:             Thu Jan 14 10:16:15 2016

Check interval:           15552000 (6 months)

Next check after:         Tue Jul 12 11:16:15 2016

Lifetime writes:          6266 MB

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               256

Required extra isize:     28

Desired extra isize:      28

Journal inode:            8

First orphan inode:       1461674

Default directory hash:   half_md4

Directory Hash Seed:      cd152f54-6921-4fc6-b0a7-6d55936e476f

Journal backup:           inode blocks

Journal features:         journal_incompat_revoke

Journal size:             128M

Journal length:           32768

Journal sequence:         0x0016adc6

Journal start:            20825

gentoo-amd64 wrc # 
```

----------

## s4e8

Sound good, if you need nanoseconds timestamp, you can add feature extra_isize.

I have a seperate boot&root partition, it's easy to do a backup: boot recovery initrd, tar rootpart to any datapart, format and untar.

 *wrc1944 wrote:*   

> 
> 
> ```
> gentoo-amd64 wrc # dumpe2fs -h /dev/sda11
> 
> ...

 

----------

