Web server : 22:05:01 up 566 days, 10:38, 0 users, load average: 0.04, 0.03, 0.02
Mail server: 09:04:10 up 573 days, 15:16, 0 users, load average: 0.16, 0.04, 0.01
Name server: 22:04:16 up 573 days, 21:34, 0 users, load average: 0.02, 0.05, 0.00
Simplicity isn’t always better. Management of distribution counts for a lot.
In any case, choose which ever platform you’re comfortable with.
StuartFrom: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Tom Lahti
Sent: Friday, 3 April 2009 07:17
To: Agnislav Onufrijchuk
Subject: Re: [rt-users] What software is recommended for high-loaded RT3.8-latest?
I have no enough experience with Slackware. AFAIK, it’s simple as BSD. Is it true?
I second the Slackware vote. I use it for everything. It’s the ultimate
distro for reliability-through-simplicity. Install nothing you don’t need.
If you don’t need xxgdb on your production server, don’t install it. (I
don’t even have X installed on my servers, but that’s just me).
Incidentally I frequently have servers go 200 days + without so much as a
reboot, even high volume FTP servers like this one:
13:13:47 up 246 days, 1:53, 2 users, load average: 0.23, 0.14, 0.05
AFAIK, they’re all provide good data safety. Now we’re using MySQL && InnoDB, I
think XFS should be fast enough. But we may migrate to PostgreSQL. AFAIK it uses
a number of files (I may be wrong) to serve its DB. So, there can be Reiser/JFS.
Filesystems are something I’ve spent a LOT of time on, so I know something
XFS has not-so-good safety. The fsck / repair tools don’t work on very
large filesystems because they need massive amount of memory – more often
than not, more than you have. If you need to fsck XFS, odds are you’ll be
formatting it instead. That said, it is deliciously fast and scalable when
properly optioned. Use a RAID controller with battery backup and you should
be fine; otherwise turn off write-back caching. Or, test your backups
frequently for restorability.
reiserfs is similiar to XFS with safety. A fsck almost never works because
everything’s a tree – once the tree is scrambled, everything in the tree
below that point is scrambled too. This is even a bigger risk if you don’t
make the filesystem with notail. You’ll be formatting, not fsck’ing. It
also doesn’t scale well and its performance with large files is horrid.
JFS on the other hand, has wonderful repair tools and decent scalability.
Unfortunately, the performance of JFS degrades exponentially with the number
of inodes used (files & directories) as it searches everything rather
linearly, and the inode structure is necessarily inefficient to make it
easily repairable. Not recommended for a filesystem with gobs and gobs of
small files. (Unfortunately, I have two 12TB RAID arrays formatted JFS with
over 14 million small files on them, and if they weren’t in production, I’d
change it in a heart-beat).
ext4 is no longer in development mode and is considered production quality
(in kernel 2.6.28 and newer). I highly recommend using it over the other
options. It is extent-based rather than block-mapped (if you format it as
such), it has the reliability of ext3 and then some (as the journal is
checksummed), and its even faster with lots of small files than reiser if
you create the filesystem with the dir_index option (which creates a hash of
directory entries that is even faster than reiser’s b-tree). It even fsck’s
faster than ext3 because it skips unallocated space.
In short: XFS is fast and not reliable. JFS is very reliable, but slow.
Reiserfs is a pitiful joke (which can used successfully by the daring &
lucky). ext4 gives you everything you always asked for: the speed of XFS
(ok, almost), the fast lookups of reiser, and the reliability of JFS
BIT Statement LLC
(425)251-0833 x 117
Community help: http://wiki.bestpractical.com
Commercial support: firstname.lastname@example.org
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com