Slashdot Mirror
Which Partition Types Are Superior?
digitalmonkey2k1 writes: "I am currently planning on running an Apache web server and a small ftp on my pc. There are so many file systems that Linux can support now that I'm not certain what ones should be used for certain features. If anyone knows of a comparison list between them, somthing to give a pro/con method of deciding the best sort of configuration It would be greatly appreciated."
DOS-type partitions are the most common on PCs, the most expected, and the easiest to deal with.
Ext3 is basically ext2 with journalling. It performs better than Ext2, though. In a pinch you can always mount it as ext2.
You're not running anything exotic. Stick with the standards.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I like Reiserfs the best. That's to say: it is fast, is a journal filesystem and it's fast.
/usr/local/mp3 resides on a partition that seems to have some errors on the disk. I lost several mp3s before I realized that the disk was screwed up. Nope, you don't get any early warnings from reiserfs.
As to reliability: if you've got good hardware, there shouldn't be any troubles at all. I for one, don't have good hardware.
Their repair tools suck, by the way.
So why do I keep using it? It's fast, is suse's default filesystem and it's fast.
I use it for the document root of my webservers. It offers faster access to the files themselves, while having very good fault tolerance.
I serve very few dynamic documents - I'm getting alot of milage out of small machines. My sites have a deep directory structure, with fairly few files in each. ReiserFS shines for this layout.
I tested several different FS for this application, ReiserFS won for me.
Oh yeah, the other benefit is the relative ease of install and upgrade.
The XFS command line utilities seem to be less effective than the Bestbits patches & utils, and the Samba 2.2.1a support seems to be a bit off with its handling of recursive descents and inheritance. To be fair on both counts, I'm still learning the file system, and the problems could be all mine.
I'd thought about ReiserFS, but I really need those ACLs.
Just some thoughts. Any errors are all mine. Please feel free to correct. I have no pride.
"Laugh Quietly- tomorrow is your turn to be rong."
This FS doesn't fragment file around partition space, major advantage if you install in hardware RAID. Fragmentation is a big problem for performance, so if it doesn't happen you have a good access time. I use ReiserFS on SuSE and Mandrake, it is fast/good, doesn't loose data and I tried the journaling by shutdonw bad my isntallation many times before a fresh install, never lost a single file, this amazed me since I dilike the fschk everytime maximal mount count and a forced unmounted FS situation happened.
Try ReiserFS. Too bad RedHat 7.2 decide not to support ReiserFS, I will give up - with regreat - on RedHat.
The question asked for information about partitition schema, not file systems. And yet almost every post so far has been about file systems.
h andbook/install-steps.html
/opt, /etc/, /usr/local, and so on, the BSD system is very rigid--there's even a man page about where things belong.)
n ual/ref-guide/ch-partitions.html
/.'s main page: The FreeBSD handbook (first link above) was just (48 hours ago) released in its second edition. This is a significant documentation change, and all the daemons are celebrating. Join us!
IMHO, if you want a superior partition scheme, you should not use the linux system, which is identical in structure to the Microsoft DOS system. Instead, read about the BSD partition (and slice) system. See section 2.5.2 of the (new) 2d edition handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
In BSD, the Microsoft-Linux concept of partitions is preserved as "slices" that exist to hold collections of files systems. (In FreeBSD, you can man hier(8) to read more about this. Unlike linux, where every vendor puts things in
Another option in BSD is the use of what are called "dangerously dedicated" system where the entire disk becomes one slides, with no other partition. Read more about this in the handbook. There's even information about working with different flavors of partition types.
I suppose to give 'equal time' we should give a link to the Microsoft/Linux partition scheme, so here one is:
http://www.redhat.com/docs/manuals/linux/RHL-7-Ma
FYI-- here's some news you won't see on
I'm running apache and ftp right now, and average traffic is about 20 hits per day. At this order of magnitude, or anywhere near it, it really doesn't matter.
Ceci n'est pas une sig
I assume he means under Linux. The NTFS driver for Linux is still unstable for writing.
Why even go as far as downloading a specific distro for it?
/dev/hdax and changing the fs type to ext3 in etc/fstab. Piece of cake...
I converted my slackware 8.0 system to ext3 in about 30 minutes. It's as simple as compiling a kernel with ext3 support, run tune2fs -j -Jsize=10
You're a real bright one, aren't you? "Didn't realize"? XFS, ReiserFS, and JFS are different filesystems; they're not ext2. Ext3 is ext2, but with a journal file added and journaling turned on. They're the same filesystem. It's even a bit disingenuous (though still correct) to say "Ext2 systems can mount ext3 filesystems," because there's no such thing as an ext3 filesystem -- just an ext2 filesystem that can, when mounted by the right kernel, support journaling.
I don't really even know why someone would want to use ext3 anyway. Unless they've made some serious improvements in the past few months, the filesystem still writes at 50% the speed of ext2 (since all data is written twice). The only thing it has going for it is its interoperability with ext2, but that's really a perfidious "feature": systems that don't need journaling should just use ext2 to avoid the massive performance hit, and systems that do need journaling (namely, servers) have no reason to have their journaling filesystems compatible with ext2, and should use one of the high-performance journaling FS's.
It is for this reason that I'm switching my machines to ext3. IMHO corrupted files after a crash are just as intolerable as a corrupted filesystem. (ext3 does have a reiserfs-like metadata-only journaling mode, but by default it journals everything - at a small performance cost of course).
Other problems with journaling file systems are that they are more complex, less mature, and have appeared only more recently in the Linux kernel, meaning there is a higher probability that they have some problem.
If you can't tolerate the few minutes of downtime resulting from an fsck, then a journaling file system is not going to help you either since machines become unavailable for lots of other reasons. In that case, you need network mirroring with a hot failover. Journaling file systems are more about convenience than any particularly rational engineering tradeoff.
Altogether, my recommendation is: don't pick software just because it's hot and new. For most users, ext2 with Apache makes a great web server platform. Apache is fast enough for any kind of Internet connection you are likely to have (Microsoft could probably serve all their static content from a single Apache server). If you like the convenience of a journaling file system and don't mind the performance hit, maybe you want to consider ReiserFS, which offers a lot of other useful features.
Excellent point - a brief google search found this page, a summary of the performance of ext2, ext3, jfs, xfs, vfat, and reiserfs.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Here's a report on performance of some of these file systems: http://www.osdl.org/reports/journal_fs/. Obviously, performance is only one factor to consider when choosing a file system, so YMMV.
Per Red Hat's RHCE training, ReiserFS is explicitly designed for the case of extremely fast access to many small files. It also uses space more efficiently with small files than any other filesystem on Linux, because it is able to glue together the small tails of the files into shared sectors.
/boot partition, and make that partition ext2 or ext3. Alternately, you can add the 'notails' option to your /etc/fstab file to turn off tail packing. If you aren't using many small files, this will not be a huge loss.
Example: You write a 513-byte file to a filesystem with 512-byte sectors. On other FS types, that file will take 2 sectors. On Reiser, it will take 1 sector plus change. Numerous small files of this type can have their tails packed into the same shared sector. I do not know the overhead in bytes per file, and thus don't know how many tails you can put into a given sector.
It also handles a very large number of files in the same directory well. Most other FS types have problems if you dump 10,000 files into a directory. It is my understanding that Reiser deals with this extremely well.
However, there is one drawback. If you are using LILO, the tail packing can cause you much grief. Lilo does not understand tails. It will be unable to execute its own second part or the kernel itself if either has had a tail-pack done. Thus, you should likely use a separate
Mandrake 8.0 came with a 2.2 kernel with ReiserFS backported. DO NOT try to use ReiserFS with any software RAID in any Linux 2.2 kernel. Make sure you update to 2.4. I believe 8.1 comes with 2.4 standard, so it shouldn't be an issue anymore with that distribution.
There have also been numerous bugfixes in the Reiser code over the 2.4 releases, so you will probably want to go with as recent a kernel as you can. Linus' 2.4 kernel tree has the reputation of being unstable, so you may want to use Alan Cox's branch until the official tree stabilizes better.
All data is NOT WRITTEN TWICE. RAID is a solution for replicating data. Journalling file systems replicate meta-data, which is the information ABOUT a file, such as its name and where it's stored on disk. They eliminate the need for fsck, which will not recover lost data either. Before you bash it, understand it.
Although advanced journaling filesystems only journal metadata, some journaling filesystems journal everything: when a disk write happens, the entire write is written to the journal file, then it's written to the real file, then it's deleted from the journal file.
When Ext3 was first created, it COULD NOT journal metadata -- the only option was full file journaling, which was incredibly slow. Don't tell me I'm wrong, because I read the original release notes which said that metadata journaling was not available yet. I believe that Ext3 can now do metadata-only journaling -- somebody correct me if I'm wrong -- but it's a fairly recent development, within the past year or so.
This mail message from about a year ago says that metadata support was "in an early state" at the time. I don't know if it's been perfected since then or not. But the e-mail proves that at one time, Ext3 could NOT do metadata-only journaling, which flat-out disproves your post that all journaling filesystems only journal metadata.
And RAID quite frankly has nothing to do with it; I can't even imagine why you brought it up because it's absolutely irrelevant.