TERMPAPER OF CSE316
Subject:-OPERATING SYSTEM
Submitted To:-
Faculty member : Amritpal Singh
Submitted by:-
Name of student : Omkar Kumar
Section : K1108
Roll no : B26
Registration number : 11114390
INTRODUCTION
FILE SYSTEM
Ans. A file system (or filesystem) is a method to organize a data expected to return after a program terminates by providing procedure to store, retrieve and update data, as well as manage the available space on the device(s) which contain it. A file system organize data in an efficient manner and is tuned to the specific characteristics of the device. File systems can be used on many different kinds of storage devices. Each storage device uses a different kind of media. The most common storage device in use today is a hard drive whose media is a disc that has been coated with a magnetic film. The film has ones and zeros 'written' on it sending electrical pulses to a magnetic "read-write" head. Other media that are used are magnetic tape, optical disc, and flash memory. In some cases, the computer's main memory (RAM) is used to create a temporary file system for short term use.
Some file system are used on local data storage devices; others provide file access via a network protocol (e.g. NFS,SMB, or 9P clients).Some file systems are “virtual”, in the “files” supplied are computed on request (e.g. procfs)or are merely a mapping into a different file system used as a backing store. The file system manages access to both the content of files and the metadata about those files. It is responsible for arranging storage space; reliability, efficiency, and the tuning with regard to the physical storage medium are important design considerations.
Linux File System Structure
* The In Linux, everything is configured as a file. This includes not only text files, images and compiled programs (also referred to as executable), but also directories, partitions and hardware device drivers. * Each file system (used in the first sense) contains a control block, which holds information about that file system. The other blocks in the file system are in odes, which contain information about individual files, and data blocks, which contain the information stored in the individual files. * There is a substantial difference between the way the user sees the Linux file system (first sense) and the way the kernel (the core of a Linux system) actually stores the files. To the user, the file system appears as a hierarchical arrangement of directories that contain files and other directories (i.e., subdirectories). Directories and files are identified by their names. This hierarchy starts from a single directory called root, which is represented by a "/" (forward slash).
* The meaning of root and "/" are often confusing to new users of Linux. This because each has two distinct usages. The other meaning of root is a user who has administrative privileges on the computer, in contrast to ordinary users, who have only limited privileges in order to protect system security. The other use of "/" is as a separator between directories or between a directory and a file, similar to the backward slash used in MS-DOS.
* The File system Hierarchy Standard (FHS) defines the main directories and their contents in Linux and other Unix-like operating systems. All files and directories appear under the root directory, even if they are stored on different physical devices (e.g., on different disks or on different computers). A few of the directories defined by the FHS are /bin (command binaries for all users), /boot (boot loader files such as the kernel), /home (users home directories), /mnt (for mounting a CDROM or floppy disk), /root (home directory for the root user), /sbin (executable used only by the root user) and /usr (where most application programs get installed).
Linux Native File systems
Every native Linux filesystem implements a basic set of common concepts that were derived from those originally developed for Unix. (Native means that the filesystem were either developed originally for Linux or were first developed for other operating systems and then rewritten so that they would have functions and performance on Linux comparable or superior to those of filesystems originally developed for Linux.) * Several Linux native filesystems are currently in widespread use, including ext2, ext3, and ext4, ReiserFS, JFS and XFS. Additional native filesystems are in various stages of development. * These filesystems differ from the DOS/Windows filesystems in a number of ways including (1) allowing important system folders to span multiple partitions and multiple hard drives, (2) adding additional information about files, including ownership and permissions and (3) establishing a number of standard folders for holding important components of the operating system. * Linux's first filesystem was minix, which was borrowed from the Minix OS. Linus Torvalds adopted this filesystem because it was an efficient and relatively bug-free piece of existing software that postponed the need to design a new filesystem from scratch. * However, minix was not well suited for use on Linux hard disks for several reasons, including its maximum partition size of only 64MB, its short filenames and its single timestamp. But minix can be useful for floppy disks and RAM disks because its low overhead can sometimes allow more files to be stored than is possible with other Linux filesystems. * The Ext File System
The Extended File System (Ext) was introduced in April, 1992. With a maximum partition size of 2GB and a maximum file name size of 255 characters, it removed the two biggest minix limitations. However, there still was no support for the separate access, inode modification and data modification timestamps. Also, its use of linked lists to keep track of free blocks and inodes caused the lists to become unsorted and the filesystem to become fragmented
.
* The Ext2 File System
The Second Extended File System (ext2) was released in January, 1993. It was a rewrite of ext which features (1) improved algorithms that greatly improved its speed, (2) additional date stamps (such as date of last access, date of last inode modification and date of last data modification) and (3) the ability to track the state of the filesystem. Ext2 maintains a special field in the superblockthat indicates the status of the filesystem as either clean or dirty. A dirty filesystem will trigger a utility to scan the filesystem for errors. Ext2 also features support for a maximum file size of 4TB (1 terabyte is 1024 gigabytes). Consequently, it has completely superseded ext, support for which has been removed from the Linux kernel.
Ext2 is the most portable of the native Linux filesystems because drivers and other tools exist that allow accessing ext2 data from a number of other operating systems. However, as useful as these tools are, most of them have limitations, such as being access utilities rather than true drivers, not working with the most recent versions of ext2, not being able to write to ext2 or posing a risk of causing filesystem corruption when writing to ext2.
The Ext2 filesystem is a mature, stable program, and it has not evolved significantly in recent years.Several additional features, however, have been considered for inclusion.
Some of them have already been coded and are available as external patches.
Others are just planned, but in some cases, fields have already been introduced in the
Ext2 inode for them. The most significant features being considered are:
* Block fragmentation
System administrators usually choose large block sizes for accessing disks because computer applications often deal with large files. As a result, small files Stored in large blocks waste a lot of disk space. This problem can be solved by allowing several files to be stored in different fragments of the same block.
* Access Control Lists (ACL)
Instead of classifying the users of a file under three classes—owner, group, and
Others—this list is associated with each file to specify the access rights for any
Specific users or combinations of users.
Handling of transparently compressed and encrypted files
These new options, which must be specified when creating a file, allow users to transparently store compressed and/or encrypted versions of their files on disk.
* Logical deletion
An undelete option allows users to easily recover, if needed, the contents of a previously removed file.
* Journaling
Journaling avoids the time-consuming check that is automatically performed on a filesystem when it is abruptly unmounted—for instance, as a consequence of a system crash.
In practice, none of these features has been officially included in the Ext2 filesystem.
One might say that Ext2 is victim of its success; it is still the preferred filesystem adopted by most Linux distribution companies, and the millions of users who use it every day would look suspiciously at any attempt to replace Ext2 with some other filesystem that has not been so heavily tested and used.
* The EXT3 FILE SYSTEM
The ext3 file system builds upon ext2 by adding journaling capabilities to the already-proven ext2 codebase. As a journaling file system, ext3 always keeps the file system in a consistent state, eliminating the need for lengthy file system integrity checks.
This is accomplished by writing all file system changes to an on-disk journal, which is then flushed on a regular basis. After an unexpected system event (such as a power outage or system crash), the only operation that needs to take place prior to making the file system available is to process the contents of the journal; in most cases this takes approximately one second.
Because ext3's on-disk data format is based on ext2, it is possible to access an ext3 file system on any system capable of reading and writing an ext2 file system (without the benefit of journaling, however). This can be a sizable benefit in organizations where some systems are using ext3 and some are still using ext2.
These improvements provide the following advantages:
* Availability
After an unexpected power failure or system crash (also called an unclean system shutdown), each mounted ext2 file system on the machine must be checked for consistency by the e2fsckprogram. This is a time-consuming process that can delay system boot time significantly, especially with large volumes containing a large number of files. During this time, any data on the volumes is unreachable.
It is possible to run fsck -n on a live filesystem. However, it will not make any changes and may give misleading results if partially written metadata is encountered.
If LVM is used in the stack, another option is to take an LVM snapshot of the filesystem and run fsck on it instead.
Finally, there is the option to remount the filesystem as read only. All pending metadata updates (and writes) are then forced to the disk prior to the remount. This ensures the filesystem is in a consistent state, provided there is no previous corruption. It is now possible to run fsck -n.
The journaling provided by the ext3 file system means that this sort of file system check is no longer necessary after an unclean system shutdown. The only time a consistency check occurs using ext3 is in certain rare hardware failure cases, such as hard drive failures. The time to recover an ext3 file system after an unclean system shutdown does not depend on the size of the file system or the number of files; rather, it depends on the size of the journal used to maintain consistency. The default journal size takes about a second to recover, depending on the speed of the hardware.
Note
The only journaling mode in ext3 supported by Red Hat is data=ordered (default)
.
* Data Integrity
The ext3 file system prevents loss of data integrity in the event that an unclean system shutdown occurs. The ext3 file system allows you to choose the type and level of protection that your data receives. With regard to the state of the file system, ext3 volumes are configured to keep a high level of data consistency by default.
* Speed
Despite writing some data more than once, ext3 has a higher throughput in most cases than ext2 because ext3's journaling optimizes hard drive head motion. You can choose from three journaling modes to optimize speed, but doing so means trade-offs in regards to data integrity if the system was to fail.
* Easy Transition
It is easy to migrate from ext2 to ext3 and gain the benefits of a robust journaling file system without reformatting. The Red Hat Enterprise Linux 6 version of ext3 features the following updates:
* Default Inode Sizes Changed
The default size of the on-disk inode has increased for more efficient storage of extended attributes, for example ACLs or SELinux attributes. Along with this change, the default number of inodes created on a file system of a given size has been decreased. The inode size may be selected with the mke2fs -I option, or specified in /etc/mke2fs.conf to set system-wide defaults for mke2fs.
* Note
If you upgrade to Red Hat Enterprise Linux 6 with the intention of keeping any ext3 file systems intact, you do not need to remake the file system.
New Mount Option: data_err
A new mount option has been added: data_err=abort. This option instructs ext3 to abort the journal if an error occurs in a file data (as opposed to metadata) buffer in data=ordered mode. This option is disabled by default (i.e. set as data_err=ignore).
More Efficient Storage Use
When creating a file system (i.e. mkfs), mke2fs will attempt to "discard" or "trim" blocks not used by the file system metadata. This helps to optimize SSDs or thinly-provisioned storage. To suppress this behavior, use the mke2fs -K option.
* The Ext4 File System
The ext4 file system is a scalable extension of the ext3 file system, which was the default file system of Red Hat Enterprise Linux 5. Ext4 is now the default file system of Red Hat Enterprise Linux 6, and can support files and file systems of up to 16 terabytes in size. It also supports an unlimited number of sub-directories (the ext3 file system only supports up to 32,000), though once the link count exceeds 65,000 it resets to 1 and is no longer increased.
Note
As with ext3, an ext4 volume must be umounted in order to perform an fsck.
EXT4 features
* Compatibility
Any existing Ext3 filesystem can be migrated to Ext4 with an easy procedure which consists in running a couple of commands in read-only mode (described in the next section). This means that you can improve the performance, storage limits and features of your current filesystems without reformatting and/or reinstalling your OS and software environment. If you need the advantages of Ext4 on a production system, you can upgrade the filesystem. The procedure is safe and doesn't risk your data (obviously, backup of critical data is recommended, even if you aren't updating your filesystem :). Ext4 will use the new data structures only on new data, the old structures will remain untouched and it will be possible to read/modify them when needed. This means, of course, that once you convert your filesystem to Ext4 you won't be able to go back to Ext3 again (although there's a possibility, described in the next section, of mounting an Ext3 filesystem with Ext4 without using the new disk format and you'll be able to mount it with Ext3 again, but you lose many of the advantages of Ext4).
* Bigger filesystem/file sizes
Currently, Ext3 support 16 TB of maximum filesystem size, and 2 TB of maximum file size. Ext4 adds 48-bit block addressing, so it will have 1 EB of maximum filesystem size and 16 TB of maximum file size. 1 EB = 1,048,576 TB (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). Why 48-bit and not 64-bit? There are some limitations that would need to be fixed before making Ext4 fully 64-bit capable, which have not been addressed in Ext4. The Ext4 data structures have been designed keeping this in mind, so a future update to Ext4 will implement full 64-bit support at some point. 1 EB will be enough (really until that happens. (Note: The code to create filesystems bigger than 16 TB is -at the time of writing this article- not in any stable release of e2fsprogs. It will be in future releases.)
* Sub directory scalability
Right now the maximum possible number of sub directories contained in a single directory in Ext3 is 32000. Ext4 breaks that limit and allows an unlimited number of sub directories.
* Extents
The traditionally Unix-derived filesystems like Ext3 use an indirect block mapping scheme to keep track of each block used for the blocks corresponding to the data of a file. This is inefficient for large files, specially on large file delete and truncate operations, because the mapping keeps a entry for every single block, and big files have many blocks -> huge mappings, slow to handle. Modern filesystems use a different approach called "extents". An extent is basically a bunch of contiguous physical blocks. It basically says "The data is in the next n blocks". For example, a 100 MB file can be allocated into a single extent of that size, instead of needing to create the indirect mapping for 25600 blocks (4 KB per block). Huge files are split in several extents. Extents improve the performance and also help to reduce the fragmentation, since an extent encourages continuous layouts on the disk.
* Multiblock allocation
When Ext3 needs to write new data to the disk, there's a block allocator that decides which free blocks will be used to write the data. But the Ext3 block allocator only allocates one block (4KB) at a time. That means that if the system needs to write the 100 MB data mentioned in the previous point, it will need to call the block allocator 25600 times (and it was just 100 MB!). Not only this is inefficient, it doesn't allow the block allocator to optimize the allocation policy because it doesn't knows how many total data is being allocated, it only knows about a single block. Ext4 uses a "multiblock allocator" (mballoc) which allocates many blocks in a single call, instead of a single block per call, avoiding a lot of overhead. This improves the performance, and it's particularly useful with delayed allocation and extents. This feature doesn't affect the disk format. Also, note that the Ext4 block/inode allocator has other improvements, described in detail in this paper.
* Delayed allocation
Delayed allocation is a performance feature (it doesn't change the disk format) found in a few modern filesystems such as XFS, ZFS, btrfs or Reiser 4, and it consists in delaying the allocation of blocks as much as possible, contrary to what traditionally filesystems (such as Ext3, reiser3, etc) do: allocate the blocks as soon as possible. For example, if a process write()s, the filesystem code will allocate immediately the blocks where the data will be placed - even if the data is not being written right now to the disk and it's going to be kept in the cache for some time. This approach has disadvantages. For example when a process is writing continually to a file that grows, successive write()s allocate blocks for the data, but they don't know if the file will keep growing. Delayed allocation, on the other hand, does not allocate the blocks immediately when the process write()s, rather, it delays the allocation of the blocks while the file is kept in cache, until it is really going to be written to the disk. This gives the block allocator the opportunity to optimize the allocation in situations where the old system couldn't. Delayed allocation plays very nicely with the two previous features mentioned, extents and multiblock allocation, because in many workloads when the file is written finally to the disk it will be allocated in extents whose block allocation is done with the mballoc allocator. The performance is much better, and the fragmentation is much improved in some workloads.
* Fast fsck
Fsck is a very slow operation, especially the first step: checking all the inodes in the file system. In Ext4, at the end of each group's inode table will be stored a list of unused inodes (with a checksum, for safety), so fsck will not check those inodes. The result is that total fsck time improves from 2 to 20 times, depending on the number of used inodes (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). It must be noticed that it's fsck, and not Ext4, who will build the list of unused inodes. This means that you must run fsck to get the list of unused inodes built, and only the next fsck run will be faster (you need to pass a fsck in order to convert an Ext3 filesystem to Ext4 anyway). There's also a feature that takes part in this fsck speed up - "flexible block groups" - that also speeds up filesystem operations.
* Journal checksumming
The journal is the most used part of the disk, making the blocks that form part of it more prone to hardware failure. And recovering from a corrupted journal can lead to massive corruption. Ext4 checksums the journal data to know if the journal blocks are failing or corrupted. But journal checksumming has a bonus: it allows one to convert the two-phase commit system of Ext3's journaling to a single phase, speeding the filesystem operation up to 20% in some cases - so reliability and performance are improved at the same time. (Note: the part of the feature that improves the performance, the asynchronous logging, is turned off by default for now, and will be enabled in future releases, when its reliability improves)
* "No Journaling" mode
Journaling ensures the integrity of the filesystem by keeping a log of the ongoing disk changes. However, it is known to have a small overhead. Some people with special requirements and workloads can run without a journal and its integrity advantages. In Ext4 the journaling feature can be disabled, which provides a small performance improvement.
* Online defragmentation
While delayed allocation, extents and multiblock allocation help to reduce the fragmentation, with usage filesystems can still fragment. For example: You write three files in a directory and continually on the disk. Some day you need to update the file of the middle, but the updated file has grown a bit, so there's not enough room for it. You have no option but fragment the excess of data to another place of the disk, which will cause a seek, or allocate the updated file continually in another place, far from the other two files, resulting in seeks if an application needs to read all the files on a directory (say, a file manager doing thumbnails on a directory full of images). Besides, the filesystem can only care about certain types of fragmentation, it can't know, for example, that it must keep all the boot-related files contiguous, because it doesn't know which files are boot-related. To solve this issue, Ext4 will support online fragmentation, and there's a e4defrag tool which can defragment individual files or the whole filesystem.
* Inode-related features
Larger inodes, nanosecond timestamps, fast extended attributes, inodes reservation... * Larger inodes: Ext3 supports configurable inode sizes (via the -I mkfs parameter), but the default inode size is 128 bytes. Ext4 will default to 256 bytes. This is needed to accommodate some extra fields (like nanosecond timestamps or inode versioning), and the remaining space of the inode will be used to store extend attributes that are small enough to fit it that space. This will make the access to those attributes much faster, and improves the performance of applications that use extend attributes by a factor of 3-7 times. * Inode reservation consists in reserving several inodes when a directory is created, expecting that they will be used in the future. This improves the performance, because when new files are created in that directory they'll be able to use the reserved inodes. File creation and deletion is hence more efficient. * Nanoseconds timestamps means that inode fields like "modified time" will be able to use nanosecond resolution instead of the second resolution of Ext3.
* Persistent preallocation
This feature, available in Ext3 in the latest kernel versions, and emulated by glibc in the filesystems that don't support it, allows applications to preallocate disk space: Applications tell the filesystem to preallocate the space, and the filesystem preallocates the necessary blocks and data structures, but there's no data on it until the application really needs to write the data in the future. This is what P2P applications do in their own when they "preallocate" the necessary space for a download that will last hours or days, but implemented much more efficiently by the filesystem and with a generic API. This has several uses: first, to avoid applications (like P2P apps) doing it themselves inefficiently by filling a file with zeros. Second, to improve fragmentation, since the blocks will be allocated at one time, as contiguously as possible. Third, to ensure that applications always have the space they know they will need, which is important for RT-ish applications, since without preallocation the filesystem could get full in the middle of an important operation. The feature is available via the libc posix_fallocate () interface.
* Barriers on by default
This is an option that improves the integrity of the filesystem at the cost of some performance (you can disable it with "mount -o barrier=0", recommended trying it if you're benchmarking). From this LWN article: "The filesystem code must, before writing the [journaling] commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times."
* Mount an existing Ext3 filesystem with Ext4 without changing the format
You can mount an existing Ext3 filesystem with Ext4 but without using features that change the disk format. This means you will be able to mount your filesystem with Ext3 again. You can mount an existing Ext3 filesystem with "mount -t ext4 /dev/yourpartition /mnt". Doing this without having done the conversion process described in the previous point will force Ext4 to not use the features that change the disk format, such as extents, it will use only the features that don't change the file format, such as mballoc or delayed allocation. You'll be able to mount your filesystem as Ext3 again. But obviously you'll be losing the advantages of the Ext4 features that don't get used...
How to Determine File System Type?
ANS:-To determing your linux file system type, run the following command in terminal as a root user.
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.
EXT2 vs EXT3 vs EXT4
Ext2, ext3 and ext4 are all filesystems created for Linux. This page 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”.
.
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.
Comparison of Ext2, Ext3 and Ext4 Performance
The goal of this post is to study the sequential read and write performance that one can get from a RAID array using various local file systems available in Linux, specifically the ext2, ext3 and ext4 file systems. Ext3 file system adds journal feature to ext2 for better reliability. Ext4 is an incremental update to ext3; it has new features such as being able to create up to 1 exabyte volumes and up to 16 terabyte files. It introduces further performance-related enhancements such as using checksums in the journal, using extents (rather than block maps) and delayed block allocation that improve large file performance.
The operating system used in this study is Red Hat Enterprise Linux 5 U4. Installing the e4fsprogs rpm enables using the ext4 file system tools. Ext4 is included in this OS version as a Technology Preview and is not officially supported. However, because of the new features ext4 provides, it is gaining more popularity. The benchmark results show how much performance increase can be expected from the current ext4 system included with Red Hat Linux.
Two Dell PowerVault MD 1200 RAID arrays are used for these experiments. Each array contains twelve 450 GB 15K rpm SAS6 disks. The storage is configured as a single RAID 5 volume spanning over 24 disks. A Dell PowerEdge R710 server with a PERC H800 card is used to connect to the arrays. First port of the H800 card is connected to the first array and the second port is connected to the second array. We used the IOzone benchmark version 3.327 available from www.iozone.org. The read ahead setting on the OS was set to 8192 sectors to improve sequential read performance using the blockdev command. For this study, the defaults were used for the other settings however the performance can be further tuned by modifying other OS and storage settings.
Bibliography
* http://kernelnewbies.org/Ext4 * http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-filesystem-ext3.html * http://oreilly.com/catalog/linuxkernel2/chapter/ch17.pdf * http://en.community.dell.com/techcenter/high-performance-computing/w/wiki/2290.aspx 