Skip to main content

Linux FileSystems Ext2 vs Ext3 vs Ext4

Linux File Systems: Ext2 vs Ext3 vs Ext4


ext2, ext3 and ext4 are all filesystems created for Linux. This article explains the following:
  • High level difference between these filesystems.
  • How to create these filesystems.
  • How to convert from one filesystem type to another.
Ext2
  • Ext2 stands for second extended file system.
  • It was introduced in 1993. Developed by Rémy Card.
  • This was developed to overcome the limitation of the original ext file system.
  • Ext2 does not have journaling feature.
  • On flash drives, usb drives, ext2 is recommended, as it doesn’t need to do the over head of journaling.
  • Maximum individual file size can be from 16 GB to 2 TB
  • Overall ext2 file system size can be from 2 TB to 32 TB
Ext3
  • Ext3 stands for third extended file system.
  • It was introduced in 2001. Developed by Stephen Tweedie.
  • Starting from Linux Kernel 2.4.15 ext3 was available.
  • The main benefit of ext3 is that it allows journaling.
  • Journaling has a dedicated area in the file system, where all the changes are tracked. When the system crashes, the possibility of file system corruption is less because of journaling.
  • Maximum individual file size can be from 16 GB to 2 TB
  • Overall ext3 file system size can be from 2 TB to 32 TB
  • There are three types of journaling available in ext3 file system.
    • Journal – Metadata and content are saved in the journal.
    • Ordered – Only metadata is saved in the journal. Metadata are journaled only after writing the content to disk. This is the default.
    • Writeback – Only metadata is saved in the journal. Metadata might be journaled either before or after the content is written to the disk.
  • You can convert a ext2 file system to ext3 file system directly (without backup/restore).
Ext4
  • Ext4 stands for fourth extended file system.
  • It was introduced in 2008.
  • Starting from Linux Kernel 2.6.19 ext4 was available.
  • Supports huge individual file size and overall file system size.
  • Maximum individual file size can be from 16 GB to 16 TB
  • Overall maximum ext4 file system size is 1 EB (exabyte). 1 EB = 1024 PB (petabyte). 1 PB = 1024 TB (terabyte).
  • Directory can contain a maximum of 64,000 subdirectories (as opposed to 32,000 in ext3)
  • You can also mount an existing ext3 fs as ext4 fs (without having to upgrade it).
  • Several other new features are introduced in ext4: multiblock allocation, delayed allocation, journal checksum. fast fsck, etc. All you need to know is that these new features have improved the performance and reliability of the filesystem when compared to ext3.
  • In ext4, you also have the option of turning the journaling feature “off”.

Warning: Don’t execute any of the commands given below, if you don’t know what you are doing. You will lose your data!

Creating an ext2, or ext3, or ext4 filesystem

Once you’ve partitioned your hard disk using fdisk command, use mke2fs to create either ext2, ext3, or ext4 file system.

Create an ext2 file system:
mke2fs /dev/sda1

Create an ext3 file system:
mkfs.ext3 /dev/sda1
(or)
mke2fs –j /dev/sda1

Create an ext4 file system:
mkfs.ext4 /dev/sda1
(or)
mke2fs -t ext4 /dev/sda1

Converting ext2 to ext3

For example, if you are upgrading /dev/sda2 that is mounted as /home, from ext2 to ext3, do the following.
umount /dev/sda2
tune2fs -j /dev/sda2
mount /dev/sda2 /home

Note: You really don’t need to umount and mount it, as ext2 to ext3 conversion can happen on a live file system. But, I feel better doing the conversion offline.

Converting ext3 to ext4

If you are upgrading /dev/sda2 that is mounted as /home, from ext3 to ext4, do the following.
umount /dev/sda2
tune2fs -O extents,uninit_bg,dir_index /dev/sda2
e2fsck -pf /dev/sda2
mount /dev/sda2 /home

Again, try all of the above commands only on a test system, where you can afford to lose all your data.


What is Journaling?



Journaling is only used when writing to a disk and it acts as a sort of punch clock for all writes. This fixes the problem of disk corruption when things are written to the hard drive and then the computer crashes or power is lost. Without a journal the operating system would have no way to know if the file was completely written to disk.
With a journal the file is first written to the journal, punch-in, and then the journal writes the file to disk when ready. Once it has successfully written to the disk, it is removed from the journal, punch-out, and the operation is complete. If power is lost while being written to disk the file system can check the journal for all operations that have not yet been completed and remember where it left off.
The biggest downside to journaling is that it sacrifices some performance in exchange for stability. There is more overhead to write a file to disk but file systems get around this overhead by not writing the full file to the journal. Instead only the file metadata, inode, or disk location is recorded before actually being written to disk.

Done..

Comments

Post a Comment

Popular posts from this blog

Docker Container Management from Cockpit

Cockpit can manage containers via docker. This functionality is present in the Cockpit docker package. Cockpit communicates with docker via its API via the /var/run/docker.sock unix socket. The docker API is root equivalent, and on a properly configured system, only root can access the docker API. If the currently logged in user is not root then Cockpit will try to escalate the user’s privileges via Polkit or sudo before connecting to the socket. Alternatively, we can create a docker Unix group. Anyone in that docker group can then access the docker API, and gain root privileges on the system. [root@rhel8 ~] #  yum install cockpit-docker    -y  Once the package installed then "containers" section would be added in the dashboard and we can manage the containers and images from the console. We can search or pull an image from docker hub just by searching with the keyword like nginx centos.   Once the Image downloaded we can start a contai
Post a Comment
Read more

Remote Systems Management With Cockpit

The cockpit is a Red Hat Enterprise Linux web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment. In RHEL 8 Cockpit is the default installation candidate we can just start the service and then can start the management of machines. For RHEL7 or Fedora based machines we can follow steps to install and configure the cockpit.  Following are the few features of cockpit.  Managing services Managing user accounts Managing and monitoring system services Configuring network interfaces and firewall Reviewing system logs Managing virtual machines Creating diagnostic reports Setting kernel dump configuration Configuring SELinux Updating software Managing system subscriptions Installation of cockpit package.  [root@rhel8 ~] #  dnf   install cockpit cockpit-dashboard  -y  We need to enable the socket.  [root@rhel8 ~] #  systemctl enable --now cockpit.socket If firewall is runnin
Post a Comment
Read more

Containers Without Docker on RHEL/Fedora

Docker is perfectly doing well with the containerization. Since docker uses the Server/Client architecture to run the containers. So, even if I am a client or developer who just wants to create a docker image from Dockerfile I need to start the docker daemon which of course generates some extra overhead on the machine.  Also, a daemon that needs to run on your system, and it needs to run with root privileges which might have certain security implications. Here now the solution is available where we do not need to start the daemon to create the containers. We can create the images and push them any of the repositories and images are fully compatible to run on any of the environment.  Podman is an open-source Linux tool for working with containers. That includes containers in registries such as docker.io and quay.io. let's start with the podman to manage the containers.  Install the package  [root@rhel8 ~] # dnf install podman -y  OR [root@rhel8 ~] # yum
1 comment
Read more