HOWTO: Tweak your ext3 filesystem for a performance boost

[Xk2c]

Have a look at:
Some ext3 Filesystem Tips
http://forums.gentoo.org/viewtopic-t-305871.html

and
http://forums.gentoo.org/viewtopic.p...252486#3252486

also.

[efreddi]

Great HOWTO!
I really boosted the speed of my Dell Latitude C600 following this howto.
In my opinion it's worth to do it on a laptop since the battery will avoid any sudden power down, I would think twice instead on a desktop.

Thanks a lot!


Elia

[GoldBuggie]

Great HOWTO!
I really boosted the speed of my Dell Latitude C600 following this howto.
In my opinion it's worth to do it on a laptop since the battery will avoid any sudden power down, I would think twice instead on a desktop.

Thanks a lot!


Elia

Happy you liked it

[ferd]

Amazing performance increase for a couple of lines of code. I found this while trying to solve another problem. The other problem remains, but who cares? I will be able to solve it in half the time because of this.

[mdan]

Tried this on my 700mhz amd desktop numerous times, in different order, always booted readonly, and then it had trouble unmounting file systems on reboot, forcing a check of /dev/hdc7 (my root partition).

Is it possible I don't need the " rootflags=data=writeback" option in grub?

From what I understand, my system mounts / as read-only ext2 and later parses
/etc/fstab to remount it as ext3. Mightn't the "data=writeback" option be enough to enable this during the remount?

Also, how much could performance be boosted by compiling my own kernel?

Thanks,
Dan

[GoldBuggie]

Is it possible I don't need the " rootflags=data=writeback" option in grub?

You can live without this option. Just enabled it in fstab for the ext3 filesystem. Check to see that it is enabled thrue

sudo tune2fs -l /dev/hda1

Replace /dev/hda1 with your ext3 partition

Also, how much could performance be boosted by compiling my own kernel?

There are subjective and objective approaches and answers to this. But since I am a compile kernel freak I would go with compiling it. But the performance increase depends on what options you choose and you also have to consider for what type of system you are building it for.

For me there are some ubuntu defaults that I change since they try to cover a broader audience.

Also there are better memory inprint considerations to consider when compiling your own kernel. Smaller kernel = smaller inprint.

[vbgunz]

I have several questions. First is, my root partition is hda3 not hda1. This means, in your how to, where ever I see hda1, change it to hda3. I did this, is this correct?. I am not sure how much of a speedup I got on a two year old $600 box but the following is my results divided by 5 runs.

$ sudo hdparm -tT /dev/hda3
/dev/hda3:
 Timing cached reads:   1242 MB in  2.00 seconds = 620 MB/sec
 Timing buffered disk reads:  101 MB in  3.00 seconds =  32.25 MB/sec

I am not sure if this is good, bad, fair or simply incorrect *but* those are my results. I've, done a bit of tweaking in the last couple of days on a new Edgy Eft install because *Nautilus* is extremely slow at traversing some directories on the root partition. I still haven't noticed anything to speed it up so I am still trying. My second question is, I've run tunefs -i *but* I am not sure about what it is I am reading.

tune2fs 1.39 (29-May-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d0018f51-0ee6-4414-a142-0111cde0fab3
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super
Default mount options:    journal_data_writeback
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1465920
Block count:              2929854
Reserved block count:     146492
Free blocks:              1954308
Free inodes:              1307743
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16288
Inode blocks per group:   509
Last mount time:          Sun Oct  8 23:34:39 2006
Last write time:          Sun Oct  8 23:34:39 2006
Mount count:              22
Maximum mount count:      30
Last checked:             Wed Dec 31 19:00:00 1969
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       817243
Journal backup:           inode blocks

Does anything appear off in relation to this how to or does all seem correct?

My third question is, I have my home partition separated from root.Do I have to do this how to again for my home partition OR should I just leave it alone?

Fourth question is, Whats the downside again? Some people say, old data might crop up on a crash or something *but* what is this old data? whats happening exactly? I mean, if I open a file, write to it and save it, it doesn't actually get saved when I save it? What is a possible case of where data might be reverted to something old? Does this inadvertently affect the home partition? Sorry for the so many part question

Thank you for your help and time on this, I really appreciate it!

[GoldBuggie]

First is, my root partition is hda3 not hda1. This means, in your how to, where ever I see hda1, change it to hda3. I did this, is this correct?.

That is a correct observation.

I have my home partition separated from root.Do I have to do this how to again for my home partition OR should I just leave it alone?

You must do this configuration for that partition as well if you want the effects for the files on that partition as well. If it is benefitial or not depends on what you do but I'm guessing that the work and fun you do with your computer you mostly work with files in your home directory so applying this tweak to your home is maybe more important then doing it to root.

About using

hdparm -tT

for testing the difference....I would say that the test that hdparm -tT provides is not an accurate test for this tweak. You need a tool that stresses the filesystem more.

I've done some tests using bonnie++(which lies on my internal wiki, must get a provider for my wiki as a christmas gift) which is a better and more accurate tool for this job.

My second question is, I've run tunefs -i *but* I am not sure about what it is I am reading.

Just note that
Default mount options: says journal_data_writeback so that you can reassure yourself that the filesystem tweak was applied.

Fourth question is, Whats the downside again? Some people say, old data
might crop up on a crash or something *but* what is this old data?

When using this method you are saying that the meatdata that the filesystem uses may be written before actual data. This means that data may be cached for some limited time before actually getting written to the HD. Which means that the cpu can work on other tasks and when those "other tasks" are finished or isn't so cpu intensive the cached data is written to disk. If your computer should crash before your cach has been flushed you will loose that data. You can tweak the time between metadata and cachflush if you want at the expense of speed. Thus if your computer crashed before a flush the "old" data will still be on the HD since the new data hasn't actually been written to the HD yet.

*Nautilus* is extremely slow at traversing some directories on the root partition

A last tweak that you might want to use is

tune2fs -O dir_index /dev/hda1
e2fsck -D /dev/hda1

This enabled the filesystem to use the b-tree algorithm for filesearching and may improve your responce time if you have many files and/or directories on your HD.

Hope this helps

cheers
GoldBuggie

[vbgunz]

Wow, I really didn't expect for you to answer every question I really appreciate it very much. Thank you

How exactly would you recommend running the last command "e2fsck -D"? I ask because I tried to run it but got this warning which is really scary:

WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.

I didn't run it at all *but* how would I do it if I wanted too? I mean, how would I unmount the root partition and still have a useable box? Is it even possible? Thank you very much for your time and patience again!

PS. The only reason I went tweak crazy in the last couple of days is because of Nautilus. It really is very slow whereas everything is snappier than ever. Thanks again!

[vbgunz]

I think I just did it. I booted up with the livecd and ran it. It seemed to do something. I hope this was correct as I do not see any problems when booting back into the system.

Here is just one of the problems I see in Nautilus acting slow. Using the filetree on the left, I drop the arrows and navigate to /usr/share/ ... thats it, here is where it freezes. If I launch "gksudo nautilus", without changing its preferences at all, I have problems navigating to other directories like /proc and looking around. Other than Nautilus running slow, I am boggled about it as I constantly have 16 gui apps launching and running at lightening speed. This problem with Nautilus occurs either with all apps on screen or none at all. heh, I might just have to switch nautilus out for something else just to get the most out of Nautilus

Thanks for the tips and help, I really appreciated it!