# Migrating to ext4 from ext3 - need clarification [SOLVED]

## landon

Hi guys,

I'm considering migrating my root partition to ext4.

I've found a guide at http://kernelnewbies.org/Ext4 that outlines the steps that I need to take. I would like to get these confirmed by another ext4 user.

To recap, the commands are:

mkfs.ext4 /dev/yourfilesystem

tune2fs -O extents,uninit_bg,dir_index /dev/yourfilesystem

fsck -pDf /dev/yourfilesystem

- append "rootfstype=ext4" to grub kernel line

Are these steps still recommended? I don't want any crazy optimizations as I want a rather stable filesystem for /

Also, I'll be using the systemrescuecd 1.17 to operate on root on my 64bit system. For those in the know, are all the tools I need included?

How best should I move the data over?

Thanks in advanceLast edited by landon on Fri Apr 10, 2009 1:18 pm; edited 1 time in total

----------

## alkan

 *Quote:*   

> mkfs.ext4 /dev/yourfilesystem

  will delete all of your data in root partition. It is not migrating, it is creating ext4 from scratch.

----------

## landon

Ah, right.. I failed to mention that I'll be using the same partition, though I'll move data to a temporary location before performing the ext4 routines.

----------

## bunder

according to that doc, you shouldn't need to...

```
tune2fs -O extents,uninit_bg,dir_index /dev/yourfilesystem 

fsck -pDf /dev/yourfilesystem 
```

and whatever command the "online defrag" is...  should bring the fs from ext3 to ext4.  you might want to watch the delayed allocation stuff though, people have said they lost data that way.   :Confused: 

cheers

----------

## jcat

Just out of curiosity, if you want a stable FS without optimisation (as you say do), why not just use ext3?

Cheers,

jcat

----------

## landon

 *jcat wrote:*   

> Just out of curiosity, if you want a stable FS without optimisation (as you say do), why not just use ext3?
> 
> Cheers,
> 
> jcat

 

It appears ext4 is stable enough for me, and has the right amount of performance features. I don't mind optimizations as long as they're not questionable.

----------

## mv

 *bunder wrote:*   

> 
> 
> ```
> tune2fs -O extents,uninit_bg,dir_index /dev/yourfilesystem 
> 
> ...

 

I was surprised that several docs only mentioned these options, alhough there is more to ext4: In addition 

```
tune2fs -I256 /dev/yourfilesystem

fsck -pDf /dev/yourfilesystem

tune2fs -O extra_isize,dir_nlink,flex_bg /dev/yourfilesystem

fsck -pDf /dev/yourfilesystem
```

 activates even more features. If you want to store >2TB files and have compiled kernel support you might even want to 

```
tune2fs -O huge_file /dev/yourfilesystem
```

----------

## landon

 *mv wrote:*   

>  *bunder wrote:*   
> 
> ```
> tune2fs -O extents,uninit_bg,dir_index /dev/yourfilesystem 
> 
> ...

 

Are these options potentially damaging? I'd like to activate features that were 100% safe.

----------

## landon

It appears (through tune2fs  -l) that those options are activated by default.

----------

## mv

 *landon wrote:*   

> It appears (through tune2fs  -l) that those options are activated by default.

 

They are activated by default if you create a new filesystem usingl mkfs.ext4, because they are listed in /etc/mke2fs.conf.

I consider it not very happy that  huge_file is included in these defaults, since, as mentioned above, it requires a speciall kernel option activated (at least on 32 bit systems) which most people will not need (who really needs files >2TB?) and which probably slows down access slightly. I consider it a problem that the option is even activated by default on partitions which are not even 2TB large (which is probably the case for most people); well, /etc/mke2fs.conf does not allow conditionals...

Concerning the options themselves: An inode size of 256 does probably not cause any problems (of course, there can always be a bug somewhere, but I doubt that a problem concerning this would not have been found meanwhile). This larger inode size is used to store data like time in miliseconds and not only in seconds. I did not check, but by the name I guess that the "extra_isize" feature is needed to actually use this additional size (and not only reserve unused space for the larger inode on disk).

About the other options (i.e. features), I have no idea what they are doing: All features seem to be documented very poorly

But since they are activated by default in a new ext4 filesystem, I think that a proper conversion to ext4 should set them.

----------

## linuxtuxhellsinki

http://www.ibm.com/developerworks/linux/library/l-anatomy-ext4/index.html?S_TACT=105AGX03&S_CMP=ART

There are some links at the end of the page.

----------

