Some Ext3 Fileystem Tips

codergeek42 · 2005-06-07 23:55:00

I posted this on the Gentoo forums, but I wanted to share it with Arch users too. I'm very much an Ext3 fanboy.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license can be found here.

Overview
I'm a big fan of the Third Extended ("ext3") filesystem. It's in-kernel and userspace code has been tried, tested, fixed, and improved upon more than almost every other Linux-compatible filesystem. It's simple, robust, and extensible. In this article I intend to explain some tips that can improve both the performance and the reliability of the filesystem.

In the document, /dev/hdXY will be used as a generic partition. You should replace this with the actual device node for your partition, such as /dev/hdb1 for the first partition of the primary slave disk or /dev/sda2 for the second partition of your first SCSI or Serial ATA disk.

I: Using The tune2fs and e2fsck Utilities

Before we begin, we need to make sure you are comfortable with using the tune2fs utility to alter the filesystem options of an ext2 or ext3 partition. Please make sure to read the tune2fs man page:

$ man tune2fs

It's generally a good idea to run a filesystem check using the e2fsck utility after you've completed the alterations you wish to make on your filesystem. This will verify that your filesystem is clean and fix it if needed. You should also read the manual page for the e2fsck utility if you have not yet done so:

$ man e2fsck

:!: WARNING: Make sure any filesystems are cleanly unmounted before altering them with the tune2fs or e2fsck utilities! (Boot from a LiveCD such as Knoppix if you need to.) Altering or tuning a filesystem while it is mounted can cause severe corruption! You have been warned!

II: Using Directory Indexing

This feature improves file access in large directories or directories containing many files by using hashed binary trees to store the directory information. It's perfectly safe to use, and it provides a fairly substantial improvement in most cases; so it's a good idea to enable it:

# tune2fs -O dir_index /dev/hdXY

This will only take effect with directories created on that filesystem after tune2fs is run. In order to apply this to currently existing directories, we must run the e2fsck utility to optimize and reindex the directories on the filesystem:

# e2fsck -D /dev/hdXY

:idea: Note: This should work with both ext2 and ext3 filesystems. Depending on the size of your filesystem, this could take a long time. Perhaps you should go get some coffee

III: Enable Full Journaling

By default, ext3 partitions mount with the 'ordered' data mode. In this mode, all data is written to the main filesystem and its metadata is committed to the journal, whose blocks are logically grouped into transactions to decrease disk I/O. This tends to be a good default for most people. However, I've found a method that increases both reliability and performance (in some situations): journaling everything, including the file data itself (known as 'journal' data mode). Normally, one would think that journaling all data would decrease performance, because the data is written to disk twice: once to the journal then later committed to the main filesystem, but this does not seem to be the case. I've enabled it on all nine of my partitions and have only seen a minor performance loss in deleting large files. In fact, doing this can actually improve performance on a filesystem where much reading and writing is to be done simultaneously. See this article written by Daniel Robbins on IBM's website for more information:

http://www-106.ibm.com/developerworks/l … fs8.html#4

There are two different ways to activate journal data mode. The first is by adding data=journal as a mount option in /etc/fstab. If you do it this way and want your root filesystem to also use it, you should also pass rootflags=data=journal as a kernel parameter in your bootloader's configuration. In the second method, you will use tune2fs to modify the default mount options in the filesystem's superblock:

# tune2fs -O has_journal -o journal_data /dev/hdXY

Please note that the second method may not work for older kernels. Especially Linux 2.4.20 and below will likely disregard the default mount options on the superblock. If you're feeling adventurous you may also want to tweak the journal size. (I've left the journal size at the default.) A larger journal may give you better performance (at the cost of more disk space and longer recovery times). Please be sure to read the relevant section of the tune2fs manual before doing so:

# tune2fs -J size=$SIZE /dev/hdXY

IV: Disable Lengthy Boot-Time Checks

:!: WARNING: Only do this on a journalling filesystem such as ext3. This may or may not work on other journalling filesystems such as ReiserFS or XFS, but has not been tested. Doing so may damage or otherwise corrupt other filesystems. You do this AT YOUR OWN RISK.

Hmm..It seems that our ext3 filesystems are still being checked every 30 mounts or so. This is a good default for many because it helps prevent filesystem corruption when you have hardware issues, such as bad IDE/SATA/SCSI cabling, power supply failures, etc. One of the driving forces for creating journalling filesystems was that the filesystem could easily be returned to a consistent state by recovering and replaying the needed journalled transactions. Therefore, we can safely disable these mount-count- and time-dependent checks if we are certain the filesystem will be quickly checked to recover the journal if needed to restore filesystem and data consistency. Before you do this please make sure your filesystem entry in /etc/fstab has a positive integer in its 6th field (pass) so that it is checked at boot time automatically. You may do so using the following command:

# tune2fs -c 0 -i 0 /dev/hdXY

This concludes this filesystem tweaking guide for now. Happy hacking!

Cam · 2005-06-08 11:20:22

Nice, now I need to boot Archie and do this to my Arch install

dtw · 2005-06-08 11:51:52

codergeek - this should go on the wiki too - but wait until the switch to mediawiki is decided - nice work

Dusty · 2005-06-08 14:41:57

dibblethewrecker wrote:

but wait until the switch to mediawiki is decided - nice work

I wouldn't start giving out advice like that yet. It could be months before the switch is actuated. We move slow in this community...

Remember the "wait for AUR threads"?

Dusty

citral · 2005-06-09 15:31:33

You might also want to mount with the 'noatime' flag. F.e. I have in my fstab:

...
/dev/discs/disc0/part3 / ext3 noatime 0 1
...

What it does:

noatime
Do not update inode access times on this file system
(e.g, for faster access on the news spool to speed up
news servers).
noatime
Access timestamps are not updated when a file is read.

Normally the filesystem updates a file to stamp it when it was last accessed. I don't need this, and with a lot of file operations it might slow things down. In two years I haven't ran into any program that needed this last accessed info. The 'last modified' info is of course still updated.

phrakture · 2005-06-09 15:38:06

very nicely done, I vote wiki too 8)

codergeek42 · 2005-06-09 16:59:32

Cool. Thanks citral.

jinn · 2006-02-25 14:34:33

Sweet,

I tried it out, except for the full journaling since I am on a laptop and dont want to have to much writing to the hdd, takes battery..

Just one question, when I ran this command:
e2fsck -D /dev/hda2

It didnt even take one second.. Dont know If It really did work or now.. I ran the latest archlinux cd, and ran e2fsck from there.

cheers
Jinn

codemac · 2006-02-26 10:53:38

I did that a while ago as well, and it had the same problem for me. I never really figured it out.

Gullible Jones · 2006-02-26 19:40:33

You cannot run e2fsck on a read-write filesystem. If you want to fsck a partition from the system that's on it, you have to remount all your filesystems read-only, or e2fsck will loudly refuse to do anything, as fscking a read-write volume can cause big problems.

codemac · 2006-02-26 22:02:49

I ran the command from knoppix when it wasn't mounted.

sh__ · 2006-02-26 23:13:05

I recall that I had to run 'e2fsck -fD /dev/hdaX' to reindex all the directories (on a read-only filesystem, obviously).

Joffer · 2006-03-01 12:10:39

Can I run the dir_index tuning on a ext3 filesystem which has been created on an encrypted disk during install (aes-i586 & dm-crypt modules loaded and used during installation)

codergeek42 · 2006-03-02 06:13:13

Joffer: if the VFS can access it, I would presume so. I'm not certain, however.

aSlocum · 2006-03-02 07:10:30

i disagree with you that data=journal is faster then ordered (which is default), maybe in some cases...yes. but journal is sure the safest flag!

here is a alternative if you want to try out: the data=writeback option

in you fstab add data=writeback like this:

/dev/hda1 / ext3 defaults,data=writeback 0 1

# tune2fs -o journal_data_writeback /dev/hda1

check that is was successfull:
# tune2fs -l /dev/hda1

appending rootflags=data=writeback to your kernel line is maybe usefull but not necessary, in my standart arch kernel (2.6.15-ARCH) it results that the kernel cant mount the filesystem. without the append all went fine and writeback is also used

a german linux magazin has testet some filesystems some months ago here are the results:

transferrates in Kbyte/sec

ext2:
1gb file 39619
2gb file 28117
4gb file 25417

ext3 (journal)
1gb file 14420
2gb file 14184
4gb file 13922

ext3 (ordered/default)
1gb file 26779
2gb file 19618
4gb file 19350

ext3 (writeback)
1gb file 26796
2gb file 21108
4gb file 19108

reiser4
1gb file 61241
2gb file 64900
4gb file 34160

reiserfs (journal)
1gb file 14235
2gb file 13771
4gb file 13540

reiserfs (ordered)
1gb file 39777
2gb file 23771
4gb file 22134

reiserfs (writeback)
1gb file 42207
2gb file 21278
4gb file 20961

ext2 i really fast but its not recommend for partitions > 1gb
if you have a seperate /tmp maybe it worth to use ext2 on it!

reiser4 is the fastet fs ever seen... but personally i would NOT recommend it. i tried it some times on my new sata drive always wit latest release and the latest tools (1.05 at the moment i think). i have always errors after some reboots and the system locks by loading some kernel modules... (i had a ext2 boot and reiser4 was on /) dont know why. its always the same. different kernels and configs.. cant get it to work.
i dont like reiserfs (not 4) that much... ext3 is as fast as reiserfs and a lot safer to use in my opinion.
xfs is a really good choice if you have some BIG files like in video editing. its not in the list above but it is the 2nd fastest fs and also safe to use. never had any problems with xfs, even after a crash (where i have problems with reiserfs..). notice that xfs eats some more cpu then the ofters. but if you used to have a partition with big files... is a good, safe and fast filesystem

just my2cents

TheGrudge · 2007-05-24 11:21:03

codergeek42 wrote:

IV: Disable Lengthy Boot-Time Checks

Is it possible to do this when journaling is set to "ordered"-mode?

lloeki · 2007-05-24 12:02:22

yes you can. it is journalling safely enough to warrant a correct recover see the ibm link inthe first post for details.

Last edited by lloeki (2007-05-24 12:19:20)

TheGrudge · 2007-05-24 12:09:59

So setting all my partitions to "ordered" is safe enough... because journal_data is too slow for my laptop.
Do I have to set the "pass" value in /etc/fstab to 0 or should I leave it at it is?

# <file system>        <dir>         <type>    <options>          <dump> <pass>
none                   /dev/pts      devpts    defaults            0      0
none                   /dev/shm      tmpfs     defaults            0      0

/dev/hda2              swap          swap      defaults            0      0

/dev/hda5              /             ext3      defaults            0      1
/dev/hda1              /boot         ext3      defaults            0      2
/dev/hda6              /home         ext3      defaults            0      2
/dev/hda7              /mnt/data     ext3      defaults            0      2

Last edited by TheGrudge (2007-05-24 12:12:30)

klixon · 2007-05-24 12:13:09

TheGrudge wrote:

Do I have to set the "pass" value in /etc/fstab to 0 or should I leave it at it is?

Leave it as is... This way, if your box didn't shut down properly, it will replay the journal

TheGrudge · 2007-05-24 12:20:46

ok, thanks @ all!! Have a nice day!!

oli · 2007-05-24 22:25:14

http://www-128.ibm.com/developerworks/l … fs8.html#4

Option writeback is as good than drawing the powercord while writing to the harddrive.

slackhack · 2007-05-25 18:32:27

i just used this guide to tune my filesystems. it seemed to go pretty well, but when doing # e2fsck -D /dev/hdXY, it was instantaneous on each of the 8 partitions i tuned. some of those partitions have 20+GB of data, so i'm wondering if it actually did anything. the guide said get some coffee, so was expecting it to actually appear to be doing something. :?:

lloeki · 2007-05-25 18:53:13

oli: well, writeback is as good as using ext2... both for performance and fault-tolerance

...ext3 (+real journalling), way to go!

Last edited by lloeki (2007-05-25 18:54:40)

ataraxia · 2007-05-25 19:21:38

slackhack wrote:

i just used this guide to tune my filesystems. it seemed to go pretty well, but when doing # e2fsck -D /dev/hdXY, it was instantaneous on each of the 8 partitions i tuned. some of those partitions have 20+GB of data, so i'm wondering if it actually did anything. the guide said get some coffee, so was expecting it to actually appear to be doing something. :?:

Add an "-f" to it, I don't think it wants to do anything since the FS is clean and journaled.

jacko · 2007-11-26 22:55:10

jacko@ubuntu:~$ sudo tune2fs -O dir_index /dev/hda1
[sudo] password for jacko:
tune2fs 1.40.2 (12-Jul-2007)
jacko@ubuntu:~$ sudo e2fsck -D /dev/hda1
e2fsck 1.40.2 (12-Jul-2007)
/dev/hda1: clean, 107179/977280 files, 869991/1953897 blocks
jacko@ubuntu:~$ sudo tune2fs -O dir_index /dev/hda2
tune2fs 1.40.2 (12-Jul-2007)
jacko@ubuntu:~$ sudo e2fsck -D /dev/hda2
e2fsck 1.40.2 (12-Jul-2007)
/dev/hda2: clean, 20033/1343488 files, 281049/2685546 blocks
jacko@ubuntu:~$

I did the following commands, but I did not need a cup of coffee, in fact I could barely take a breath and it was finished. Good or bad?

I did it through ubuntu, so hda was unmounted, I verified this umount command.

Arch Linux

#1 2005-06-07 23:55:00

Some Ext3 Fileystem Tips

#2 2005-06-08 11:20:22

Re: Some Ext3 Fileystem Tips

#3 2005-06-08 11:51:52

Re: Some Ext3 Fileystem Tips

#4 2005-06-08 14:41:57

Re: Some Ext3 Fileystem Tips

#5 2005-06-09 15:31:33

Re: Some Ext3 Fileystem Tips

#6 2005-06-09 15:38:06

Re: Some Ext3 Fileystem Tips

#7 2005-06-09 16:59:32

Re: Some Ext3 Fileystem Tips

#8 2006-02-25 14:34:33

Re: Some Ext3 Fileystem Tips

#9 2006-02-26 10:53:38

Re: Some Ext3 Fileystem Tips

#10 2006-02-26 19:40:33

Re: Some Ext3 Fileystem Tips

#11 2006-02-26 22:02:49

Re: Some Ext3 Fileystem Tips

#12 2006-02-26 23:13:05

Re: Some Ext3 Fileystem Tips

#13 2006-03-01 12:10:39

Re: Some Ext3 Fileystem Tips

#14 2006-03-02 06:13:13

Re: Some Ext3 Fileystem Tips

#15 2006-03-02 07:10:30

Re: Some Ext3 Fileystem Tips

#16 2007-05-24 11:21:03

Re: Some Ext3 Fileystem Tips

#17 2007-05-24 12:02:22

Re: Some Ext3 Fileystem Tips

#18 2007-05-24 12:09:59

Re: Some Ext3 Fileystem Tips

#19 2007-05-24 12:13:09

Re: Some Ext3 Fileystem Tips

#20 2007-05-24 12:20:46

Re: Some Ext3 Fileystem Tips

#21 2007-05-24 22:25:14

Re: Some Ext3 Fileystem Tips

#22 2007-05-25 18:32:27

Re: Some Ext3 Fileystem Tips

#23 2007-05-25 18:53:13

Re: Some Ext3 Fileystem Tips

#24 2007-05-25 19:21:38

Re: Some Ext3 Fileystem Tips

#25 2007-11-26 22:55:10

Re: Some Ext3 Fileystem Tips

Board footer