(A MUST READ!!!!!) The Ultimately Fastest Ubuntu Desktop/Server You Can Have!

[hrp2171]

can you suggest a good partitioning heres what iam using

intel 1.6ghz, 720 ram
primary: 30gb ide
slave:20gb ide

Primary:
/dev/hda
hda1 = /boot 100MB FS = ext3
hda2 = / 10GB FS = xfs
hda3 = /usr aprox. 19GB <- whatever's left after creating the other 2 FS = xfs

Slave:
/dev/hdb
hdb1 = swap 720MB
hdb2 = /home aprox. 19GB FS = xfs

My reasoning: /usr is where most of the programs are going to get installed into. You could make / smaller, too. And other replies may make / smaller than my suggestion. /home is where I always download files from the net into.

If your processor is a Pentium 4 based CPU, don't forget to install the 686 kernel+restricted drivers from the repositories. Also, if you have an nVidia or ATI video card, install the binary drivers from the repositories, too.

After reconfiguring my laptop to use xfs for /, installing the 686 stuff and the ATI driver, it is just as responsive as my tower unit. That's even if I'm on batteries.

[md5hash]

Thanks alot hrp2171... I'll try that

[hrp2171]

Thanks alot hrp2171... I'll try that

Also, are you going to be dual booting with Windows on that system? Because my suggestion would have to tweaked accordingly.

[md5hash]

Also, are you going to be dual booting with Windows on that system? Because my suggestion would have to tweaked accordingly.

thanks its alot faster than before.. no i wll not use any windows os...

[md5hash]

i have a 80gb disk can you suggest a good partitioning scheme? thanks in advance..

[omega_user]

I vouch for XFS. Athough this does seem a litte exaggerated, it's proven through benchmarks that Ext3 is the worst in both realiability and speed. XFS and JFS are the best, only behind ZFS which, incredible as it is, is Sun proprietary. A bonus for XFS is the extremely low fragmentation that occurs (yes there is fragmentation, just very little). There is a way to defrag an XFS but it's not built in with Gnome, just like a bunch of other things aren't compatibile with XFS, like the partition editor. LILO too, is the only booter that works with XFS, but people who want the GRUB solely because it shows the loading bar should forget about that and think how much faster it is.

[articpenguin]

The reason why ext3 takes forever to format is because its writing the inodes out. On my 750GB it took 20 mins just to create 300Million freakin inodes. Who the hell will use up 300Million?


Thats why i use JFS. Its both more fast and more reliable than ext3 IMO

[alphacrux]

Hey guys I did alot of research way back when I was formatting my drives to install Linux for the first time and here is what all I found about filesystems. First off XFS and JFS are not the fastest. ZFS is better all around, the newest version of Rieser is MUCH faster but very unstable, also ext2 beats just about all of them in speed as it doesn't use journaling which is why most people use it for their boot directory. Although ext3 is slower, it is rock solid as far as reliability goes. I've heard a few accounts of the xfs filesystem being corrupted when there is a power shortage. I do not think that slight performace is worth putting my drives at risk unless you are backing up your system on outside media anyway. If you really want performance then just put two hard drive in a raid 0 array, that will beat any change of filesystems. If there's one thing I'm not going to mess with its my filesystem.

Also ext3 is supported across ALL versions of Linux, I think some 60 or 70% of all Linux users use it. With that many people using it you can be assured that just about any and every Linux program, no matter how obscure and no matter its functionality, will not have any problems with this filesystem. Also I'm not too sure about further development about XFS but last I heard it might be kind of shady meaning there's no assurance that further work will be done on it, and if there is that it will be backwards compatible with the previous version of XFS. I know for a fact that the rieser filesystem development is having major problems. On the other hand ext4 is already set to be the next official filesystem for Debian and ubuntu after it comes out of development and is proven to be stable enough. Ext4 fixes almost all the performance problems ext3 had, is faster, and is backwards and forwards compatible with ext3. That means right now anyone with the ext3 filesystem can mount their drives as ext4 (of which the development version is available) and if they don't like it can remount it as ext3. I personally would choose reliablity and compatibility with future file systems. If I was using unix or solaris I'd go with ZFS but since that isn't an option here I'm sticking with ext3, anyways that's my two cents.

[MonkeeSage]

A more recent benchmark set (though all micro-benchmarks should be taken with a fairly large grain of salt) shows that ext3, in metadata journaling mode (data=writeback), performs competitively with XFS under a range of typical server loads (using [no]atime or APC apparently made little difference on either FS; see stats). Scroll to the bottom for the raw stats pdf file.

Similarly, a benchmark set from a few years ago, showed that on average, taking the best and weakest points of each system, they basically are all the same. One may excel in some job that another lags in, while the other beats the first in a different area. Or at least the numbers are close enough, on average, that they are not above the signal:noise threshold. The article also shows how to do some nice speed tweaks on XFS (which is its main purpose, BTW, the benchmarks are kind of incidental).

Ps. Just to clear up a point that someone said earlier: XFS doesn't "loose" data when the journal is not cleanly flushed. ext3, in full journal mode, gives you the last inodes that were journaled as file fragments (ordered journal mode is more complicated). XFS gives you the metadata only (which points to extents with a size but no data). When ext3 is in metadata journal mode, you get the same behavior -- XFS just had a bug that caused it to write nulls ("zeros") rather than freeing the extents. It is interesting to read SGI's FAQ about XFS, starting with the Q: "Why do I see binary NULLS in some files after recovery when I unplugged the power?"

All my partitions are ext3, BTW -- and hopefully ext4 soon, like the previous poster said! :)

[articpenguin]

Ext4 wont be out until at early 2009. E2fsprogs is still not extent ready for ext4.