Paul S wrote:
> I've reinstalled hardy 4 times over the past 2 months due to the EXT3
> filesystem getting corrupted. I didn't have any such problem on gutsy,
> just hardy.
>
> I'm just running a desktop, but using crypto and lvm to put both the
> root and swap within the same partition, with a separate small /boot
> partition. All done from the alternate installer.
>
> So, after 3 installs with EXT3, I decided to try something else. I
> notice the installer offers JFS, XFS, and ReiserFS, so I picked JFS for
> the 4th reinstall.
>
> I've been running it a couple days and have purposely crashed the system
> at least 10 times and not yet had any filesystem problem. This makes me
> believe there is some bug in the EXT3 driver rather than a hardware
> problem on my harddrive. I have a Seagate Technologies harddrive.
>
> I also noticed some bugs on launchpad about similar experiences with
> EXT3, but no solutions.
>
> I read some on wikipedia and googling, but I couldn't get anything more
> than specifications .. nothing on performance comparisons among the 4.
>
> Anyone know any reason to avoid JFS or use any other?
>
> TIA,
>
I can't comment on your EXT3 problems.. In my experience, EXT3 has been
the most stable and easy to recover file system (and I have stress
tested all of them several times.) That being said, I'll share my
observations so far on the others.
I've had several minor corruption problems with JFS on at least 3
distros over several kernel versions. It was nothing jfsrepair couldn't
fix, but since is it was meta data corruption caused in unclean
shutdowns, they really shouldn't happen at all in a journaled file
system. I don't think JFS journaling is very robust. I've also
encountered lots of strange performance bottlenecks with JFS. Even
though if I create an artificial test, (with file system benchmarks, or
my own favorite, working with 2+GB Maildir spools) it surpasses all
others. But in real world use, some strange combinations end up causing
it to go slow.... sometimes the speed problems were even induced by
filenames! (for example,, if I untarred a file that contained multiple
2 gig files with .aa .ab .ac etc extensions, the untarring would slow to
a crawl.. if Instead I packed the files without the same extensions, the
problem would not occur). The biggest problem with JFS, IMO, is that
it's simply not used enough to get the kind of natural testing the other
FS's do.. for example, last year at some point, quotas were completely
broken by a kernel update, but no one even noticed for 3 point releases
of the kernel!
ReiserFS is supposed to be the fastest with small files. I call
poppycock on that one.. ReiserFS is only fast in Namesys benchmarks.
The problem with reiser is that readdir operations don't return the
filenames in the same order they were written to disk (inode order). So
if you pack thousands of small files into a directory, then try to back
them up with tar, or copy them, or search through them for a string,
your IO throughput drops to nearly 0 while the hard drive furiously
seeks randomly across the whole platter for each and every file. JFS
and XFS don't have this problem, and were much faster for hosting large
directories of small files (the Maildir test.) Even if Reiser is
superior for some tasks, I wouldn't count on it being well maintained
going forward into the future. Suse, once Reiser's largest supporter,
even switched away from the file system for this reason. And given
today's news, I don't expect this file system to gather more support
going forward.
XFS, performance wise, is probably the all around best file system. I
had no problems with XFS file system corruption, or performance on any
kind of workload (be it the maildir test or hosting 100's of GB in DVD
rips.) Unfortunately, XFS has a critical flaw (err, sorry, I mean
feature, if you ask the XFS devs) that makes it unsuitable for general
purpose File system. Unlike all other filesystem candidates, the meta
data is not written to disk in an ordered fashion. In the case of an
unclean shutdown, XFS will pad the difference with Null byte characters.
For example, lets say you are writing a 1kb file. 500 bytes got
flushed to disk before the system was interrupted, but the journal was
already updated with the 1kb filesize. When you reboot, you'll have a
1kb file, containing 500 bytes of data and 500 bytes of null. For the
love of all that is holy, *never* use XFS to hold something like an FTP
mirror. Most mirror scripts check file datestamp and filesize, but will
not be able to detect files trashed by XFS unless you do an md5sum check
on the whole thing.
EXT3, as I said, worked well for me in all generic circumstances. In a
default filesystem, however, you will run into trouble if you try to
stuff thousands of files in 1 directory. Your file system will be in
pain after 2000 files, almost unusable after 50000. You can fix this by
adding the dir_index option, after which EXT3 will perform more or less
the same as ReiserFS.
--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Locked
