Migration from Ext3 to Ext4
This article is for those who want to switch from the Ext3 file system to Ext4, while keeping all their files and directories. I will try to describe the most common errors arising in the process of migration from Ext3 to Ext4, without reinstalling the system.
Explaining the advantages and disadvantages of Ext4 is beyond the scope of this article (use the habr search tool - there’s one here ). If you do not suffer from the restrictions imposed by Ext3 and are not willing to take a chance and just go to Ext4, then think very well, do you need it? ;) On the other hand, going to Ext4, you can feel the performance gain of your file system and increase its reliability without incurring any overhead costs;)
')
An interesting point is the fact that you can try to mount the Ext3 file system as Ext4 without converting it. All you need to do is to make the appropriate file system type changes in / etc / fstab and reboot the system. In this case, you can return to Ext3 at any time.
This can be a good test if your OS is ready to support Ext4. But it should be remembered that in this case no Ext4 extensions will be included - this will just be Ext3 compatibility mode.
Make a backup of your system before continuing. It may happen that during the conversion the computer will restart and all data will be lost.
File systems will no longer be compatible with Ext3, so you need to make sure that you have Ext4 support tools for normal loading and restoring of the file system in case of failure. The latest bootloader versions, e2fsprogs, mount, and the Linux kernel include Ext4 support.
All these packages are available in unstable or experimental Debian GNU / Linux repository branches. Older versions can and will work, with the exception of e2fsprogs - this is really the minimum version to support Ext4.
As long as we convert the unmounted Ext3 to Ext4, this will be really simple procedures. In the example, we convert / dev / sdc1 mounted as / home.
The next step is to check the section for errors to make sure they are missing. We are still in Ext3:
We include new Ext4 features for the section:
After that, run the file system check for Ext4:
Errors will be found - this is normal. You can run the check a second time to make sure that the errors have disappeared.
The -D parameter when running fsck.ext4 will actually enable support for dir_index, restoring the directory index. Running with this option can be done at any time later.
Now change the / etc / fstab file to enable Ext4 for the converted partition, replacing ext3 with ext4, the other parameters may be different on your system:
Mount the section:
Congratulations if everything went well;) If not, do not panic. In the end, you followed the advice above and made a backup, right? ;) Check whether you actually installed the above toolkit (or version above) from unstable or experimental Debian branches (although maybe you are using another distribution?), If necessary, update these packages. Try again the steps above.
If / boot is a separate partition in Ext3, then for the time being we’ll leave everything as it is. Although the latest versions of grub and Ext4 support they may not be included in the distribution.
You can simply mount the partition in Ext4 without real conversion, specifying the new file system type of the partition in / etc / fstab:
Most of the new Ext4 products will not be used, but this will have little effect on the OS boot process, will it? ;) And essentially it still remains the Ext3 partition, so even the old version of grub should not have any problems with loading.
If your / boot partition is not created separately then it’s time to think about separating it into a separate area. Otherwise, be very careful not to include features that are not supported by your version of grub or update grub to the version that will support them.
Converting the root file system is somewhat more complicated, since we cannot just take it and unmount it. However, it is possible to do this without using external bootable media. But the whole process of converting the root file system will need to be done in single-user monopoly mode.
The first step is to change / etc / fstab and say use ext4 instead of ext3 for the root partition. This is important because the file system will continue to work in read-only mode and no changes will be made, as a result, it will be impossible to mount the root file system at the next boot.
Suppose that the root partition / is / dev / sda1, so after making changes to the / etc / fstab file, the line for this partition should look like this:
Now we remount the file system in read-only mode:
Run the file system check:
Here we will be told that we need to restart the system. Well, good idea. Reboot to single-user exclusive mode and re-mount the root file system in read-only mode again:
It is good that we have already edited / etc / fstab and the ext3 partition can be mounted as ext4 without prior conversion.
Next, to enable ext4 on the root file system, run:
And again we run the check for the root file system. She will find and correct mistakes, well, we already know (read above):
If you are using the 2.6.30 kernel from the Debian repository, be careful. You may need to update the initrd to add an ext4 module:
If the ext4 module is not present in the initrd then you will not be able to boot after you convert Ext3 to Ext4.
Now we are overloaded. Here, we have a fast Ext4 file system, we feel some performance gain, we have access to all Ext4 improvements. Well, almost everything, read on ...
It may seem that the conversion is complete. And this is almost true, except that all previously created files will use the bitmap map ext3 instead of extents in ext4.
No, of course, sooner or later, with subsequent modification of files, their display will also be updated in extents. But unfortunately much more files are read than written (are the compiled applications of the OS often updated?). As a result, files can be displayed in bitmap for a long time and you will not feel the power and will not reveal the full potential of ext4.
The e4defrag utility, which could rebuild files into a new mapping, is currently under development. Unfortunately, it is not complete and not ready for use on real data (at least, as they say, for now).
Fortunately, all is not lost. You can do the necessary actions using the chattr that comes with the e2fsprogs package. It allows you to set an attribute that will cause the kernel to overwrite the file in the new display extents. This can be done on a mounted and running file system. In fact, this is probably the only way to do it;)
But notice that this function is in some way still experimental and not definitively tested. Doing this may be dangerous. A syslog may simply be filled with error messages. It is advisable to check all this first on a small amount of data.
To check the extended attributes of a file (and directory), you can use lsattr:
If extents is not used, we’ll see something like this:
The dotted line is just a display of file attributes. In this case, the file has no attributes.
Now set the attribute for extents:
Display the file attributes again:
Pay attention to the “e” indicating that the file uses the extents attribute.
Check logs for scary error messages in the file system. If we do not find it, it means that the stars are favorable to us today and we can continue.
For chattr, you can transfer multiple file names. But ... Who in our time is doing something manually and one file at a time. Use magic:
Thus, we will set the extents attribute first for all files and then for all directories of the / home partition.
The same operation can be done starting from the root partition. Specifying the -xdev option will not allow trying to set the extents attribute in places where it does not need to be.
It may make sense to run these commands in single-user monopoly mode to minimize the chance that some other process will interfere with the work in parallel.
The author of these lines is not responsible if you have something breaks as a result of all the above actions. Remember that you act at your own peril and risk;) And the rest of success ...;)
This article is a fairly loose translation.
" Migrating a live system from ext3 to ext4 filesystem " (like the original to the beginning of hostilities) with some additions. ;)
Criticism, discussion, a description of one’s own experience and so on are certainly welcome…
Grounds for the transition.
Explaining the advantages and disadvantages of Ext4 is beyond the scope of this article (use the habr search tool - there’s one here ). If you do not suffer from the restrictions imposed by Ext3 and are not willing to take a chance and just go to Ext4, then think very well, do you need it? ;) On the other hand, going to Ext4, you can feel the performance gain of your file system and increase its reliability without incurring any overhead costs;)
')
Attempt to mount Ext4 without conversion.
An interesting point is the fact that you can try to mount the Ext3 file system as Ext4 without converting it. All you need to do is to make the appropriate file system type changes in / etc / fstab and reboot the system. In this case, you can return to Ext3 at any time.
This can be a good test if your OS is ready to support Ext4. But it should be remembered that in this case no Ext4 extensions will be included - this will just be Ext3 compatibility mode.
Switch to Ext4.
Recent warnings.
Make a backup of your system before continuing. It may happen that during the conversion the computer will restart and all data will be lost.
File systems will no longer be compatible with Ext3, so you need to make sure that you have Ext4 support tools for normal loading and restoring of the file system in case of failure. The latest bootloader versions, e2fsprogs, mount, and the Linux kernel include Ext4 support.
Tools.
- e2fsprogs 1.41.6
- mount 2.16
- linux-image 2.6.30
- grub 1.96 + 20090808
All these packages are available in unstable or experimental Debian GNU / Linux repository branches. Older versions can and will work, with the exception of e2fsprogs - this is really the minimum version to support Ext4.
Convert non-root file system to Ext4.
As long as we convert the unmounted Ext3 to Ext4, this will be really simple procedures. In the example, we convert / dev / sdc1 mounted as / home.
umount / dev / sdc1
The next step is to check the section for errors to make sure they are missing. We are still in Ext3:
fsck.ext3 -pf / dev / sdc1
We include new Ext4 features for the section:
tune2fs -O extents, uninit_bg, dir_index / dev / sdc1
After that, run the file system check for Ext4:
fsck.ext4 -yfD / dev / sdc1
Errors will be found - this is normal. You can run the check a second time to make sure that the errors have disappeared.
The -D parameter when running fsck.ext4 will actually enable support for dir_index, restoring the directory index. Running with this option can be done at any time later.
Now change the / etc / fstab file to enable Ext4 for the converted partition, replacing ext3 with ext4, the other parameters may be different on your system:
/ dev / sdc1 / home ext4 defaults 0 2
Mount the section:
mount / home
Congratulations if everything went well;) If not, do not panic. In the end, you followed the advice above and made a backup, right? ;) Check whether you actually installed the above toolkit (or version above) from unstable or experimental Debian branches (although maybe you are using another distribution?), If necessary, update these packages. Try again the steps above.
/ boot partition
If / boot is a separate partition in Ext3, then for the time being we’ll leave everything as it is. Although the latest versions of grub and Ext4 support they may not be included in the distribution.
You can simply mount the partition in Ext4 without real conversion, specifying the new file system type of the partition in / etc / fstab:
/ dev / sdb1 / boot ext4 defaults 0 1
Most of the new Ext4 products will not be used, but this will have little effect on the OS boot process, will it? ;) And essentially it still remains the Ext3 partition, so even the old version of grub should not have any problems with loading.
If your / boot partition is not created separately then it’s time to think about separating it into a separate area. Otherwise, be very careful not to include features that are not supported by your version of grub or update grub to the version that will support them.
Convert root filesystem to Ext4.
Converting the root file system is somewhat more complicated, since we cannot just take it and unmount it. However, it is possible to do this without using external bootable media. But the whole process of converting the root file system will need to be done in single-user monopoly mode.
The first step is to change / etc / fstab and say use ext4 instead of ext3 for the root partition. This is important because the file system will continue to work in read-only mode and no changes will be made, as a result, it will be impossible to mount the root file system at the next boot.
Suppose that the root partition / is / dev / sda1, so after making changes to the / etc / fstab file, the line for this partition should look like this:
/ dev / sda1 / ext4 defaults 0 1
Now we remount the file system in read-only mode:
mount -o remount, ro /
Run the file system check:
fsck.ext3 -pf / dev / sda1
Here we will be told that we need to restart the system. Well, good idea. Reboot to single-user exclusive mode and re-mount the root file system in read-only mode again:
mount -o remount, ro /
It is good that we have already edited / etc / fstab and the ext3 partition can be mounted as ext4 without prior conversion.
Next, to enable ext4 on the root file system, run:
tune2fs -O extents, uninit_bg, dir_index / dev / sda1
And again we run the check for the root file system. She will find and correct mistakes, well, we already know (read above):
fsck.ext4 -yfD / dev / sda1
If you are using the 2.6.30 kernel from the Debian repository, be careful. You may need to update the initrd to add an ext4 module:
update_initramfs -u
If the ext4 module is not present in the initrd then you will not be able to boot after you convert Ext3 to Ext4.
Now we are overloaded. Here, we have a fast Ext4 file system, we feel some performance gain, we have access to all Ext4 improvements. Well, almost everything, read on ...
Convert files to extents.
It may seem that the conversion is complete. And this is almost true, except that all previously created files will use the bitmap map ext3 instead of extents in ext4.
No, of course, sooner or later, with subsequent modification of files, their display will also be updated in extents. But unfortunately much more files are read than written (are the compiled applications of the OS often updated?). As a result, files can be displayed in bitmap for a long time and you will not feel the power and will not reveal the full potential of ext4.
The e4defrag utility, which could rebuild files into a new mapping, is currently under development. Unfortunately, it is not complete and not ready for use on real data (at least, as they say, for now).
Fortunately, all is not lost. You can do the necessary actions using the chattr that comes with the e2fsprogs package. It allows you to set an attribute that will cause the kernel to overwrite the file in the new display extents. This can be done on a mounted and running file system. In fact, this is probably the only way to do it;)
But notice that this function is in some way still experimental and not definitively tested. Doing this may be dangerous. A syslog may simply be filled with error messages. It is advisable to check all this first on a small amount of data.
To check the extended attributes of a file (and directory), you can use lsattr:
lsattr / home / user / foo / bar
If extents is not used, we’ll see something like this:
------------------- / home / user / foo / bar
The dotted line is just a display of file attributes. In this case, the file has no attributes.
Now set the attribute for extents:
chattr + e / home / user / foo / bar
Display the file attributes again:
----------------- e- / home / user / foo / bar
Pay attention to the “e” indicating that the file uses the extents attribute.
Check logs for scary error messages in the file system. If we do not find it, it means that the stars are favorable to us today and we can continue.
For chattr, you can transfer multiple file names. But ... Who in our time is doing something manually and one file at a time. Use magic:
find / home -xdev -type f -print0 | xargs -0 chattr + e find / home -xdev -type d -print0 | xargs -0 chattr + e
Thus, we will set the extents attribute first for all files and then for all directories of the / home partition.
The same operation can be done starting from the root partition. Specifying the -xdev option will not allow trying to set the extents attribute in places where it does not need to be.
It may make sense to run these commands in single-user monopoly mode to minimize the chance that some other process will interfere with the work in parallel.
Final word
The author of these lines is not responsible if you have something breaks as a result of all the above actions. Remember that you act at your own peril and risk;) And the rest of success ...;)
This article is a fairly loose translation.
" Migrating a live system from ext3 to ext4 filesystem " (like the original to the beginning of hostilities) with some additions. ;)
Criticism, discussion, a description of one’s own experience and so on are certainly welcome…
Source: https://habr.com/ru/post/83152/
All Articles