JFS vs EXT3 vs XFS vs ReiserFS

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,

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Derek Broughton-2]

Paul S wrote:

> Anyone know any reason to avoid JFS or use any other?

No.  I've been happily using JFS for years now (since running into frequent
problems with corruption with Reiser).
--
derek


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Karl Larsen]

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,
>
>  

    How do you know it is the file system is bad? I am using EXT3 and
while having problems with nVidia I had to just turn off the computer
many times. It came back up with small errors corrected while 7.10
booted up.

    Are you saying Hardy will not correct the small errors, or that the
errors are large and cannot be corrected?

Karl




--

        Karl F. Larsen, AKA K5DI
        Linux User
        #450462   http://counter.li.org.
   PGP 4208 4D6E 595F 22B9 FF1C  ECB6 4A3C 2C54 FE23 53A7


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Mon 28 Apr 2008 21:55:40 Paul S wrote:

>
> Anyone know any reason to avoid JFS or use any other?

My very limited experience on different FS's is as follows:

If you intend to use LVM (which I use both at work, at home, and every
family/friends computer I put my hands and ubuntu on), the FS you choose
is an important choice, when it comes the time to resize it. IIRC the LVM
howto states that ext3 and reiserf need to be unmounted to be resized,
while JFS and XFS don't. The two latter also don't support shrinking,
which IIRC is supported by the first two (but it's been a while since I
read about this, and it could have changed). If you are sure of your
partition scheme, after you add another hard disk, JFS or XFS will allow
you to add the HD to the volume group on the fly (cool, huh?).

On the minus site, ext3 doesn't allow you to recover deleted files (ext2,
while I've been *told* this can be done in reiserfs (never tried it
though). I've no information on this for JFS or XFS.

About speed, reiserfs is largely claimed to be faster if you deal with
many (several thousands) small (few kbs) files, and JFS is claimed to be
the fastest overall. I tried JFS with edgy and Feisty, and to be honest,
I didn't notice a difference (but I didn't make any objective
measurements). Just before the Gutsy cycle, I started working in the
situation where reiserfs is considered best (thousands of small data
files), so I changed to reiserfs in gutsy, and have been using it so far.

I've *never* had any particular trouble with corruption with either or
ext3, jfs or reiserfs, that was not caused by power failure or bad HD,
and for a while when I had reiser at work and jfs at home, I had an
annoyance about EA (extended attributes) on files I backed up to get the
two boxes in sync daily (I use dar on a USB key for this), but it was not
more than annoying warning messages, and no corruption was ever done (as
confirmed by rsync and diff several times).

All in all, in my limited experience, for a regular home user, any
filesystem will do just nice.

regards
FF

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Rashkae-2]

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

Karl Larsen said the following on 04/29/2008 08:09 AM:
> 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.

>     How do you know it is the file system is bad? I am using EXT3 and
> while having problems with nVidia I had to just turn off the computer
> many times. It came back up with small errors corrected while 7.10
> booted up.
>
>     Are you saying Hardy will not correct the small errors, or that the
> errors are large and cannot be corrected?

Specifically, after a normal shutdown (no power failure or anything),
when I next booted the fsck kicked in because of some irregularity that
fsck detected.  The automatic fsck failed with the error message that it
had to be done manually in read only mode.  So, I did it manually and
replied Y to each prompt that came up.  I'm not a ext3 fsck expert, so
didn't understand the messages and prompts of fsck.  After all were
corrected, I rebooted.  Once the desktop launched, I had a screen
showing only the wallpaper and an empty panel .. and no response to any
key or mouse inputs.  So, it some vital files were ruined by the fsck.
This happened 3 times previously on earlier versions of hardy, all on ext3.

I also have a second partition where I was doing some xorg driver
testing on hardy.  That partition is also ext3.  It is not encrypted nor
is it LVM, but just regular.  The last time I booted it, I got the same
fsck error messages.  I have not had time to go back to run it and see
if it's also ruined.

So far, using JFS on this reinstall, no such problems ... that's what
makes me think it's software not hardware.

regards,


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Rashkae said the following on 04/29/2008 01:02 PM:
> 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 never had a problem before hardy either with ext3 being corrupted
to be unusable.

Thanks for your comments on the others.

regards,

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Karl Larsen]

Paul S wrote:

> Rashkae said the following on 04/29/2008 01:02 PM:
>  
>> 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 never had a problem before hardy either with ext3 being corrupted
> to be unusable.
>
> Thanks for your comments on the others.
>
> regards,
>
>  

    Thinking about this I do have experience with Hardy finding fault
with a ext3  partition. I use the the same Home partition on 7.10 and
Hardy.  When I boot Hardy it finds this Home partition as flawed. But it
was just working fine on 7.10. I have to let it "fix" the partition to
use it. I go back and there is no problem.


Karl
 

--

        Karl F. Larsen, AKA K5DI
        Linux User
        #450462   http://counter.li.org.
   PGP 4208 4D6E 595F 22B9 FF1C  ECB6 4A3C 2C54 FE23 53A7


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Karl Larsen said the following on 04/29/2008 03:06 PM:
>     Thinking about this I do have experience with Hardy finding fault
> with a ext3  partition. I use the the same Home partition on 7.10 and
> Hardy.  When I boot Hardy it finds this Home partition as flawed. But it
> was just working fine on 7.10. I have to let it "fix" the partition to
> use it. I go back and there is no problem.

OK, I had that several times too.  On some occasions fsck did not
destroy any important files.  But, when it finally did, then I had to
reinstall.

Your experience adds to my idea that something is different in hardy.

regards,


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Tue 29 Apr 2008 20:00:06 Res wrote:


> So basically reiser is good for stuff like maildir mail
> spools, and probably anything else, the only thing I wouldnt run on
> reiserfs, is databases, because I want rock hard reliance, I want run
> any
> journalled FS, so its ext2 only for MySQL's data dir.

Eh, since reiserfs is journaled it should give you the reliance you asked
for, if journaling is your parameter. Also, ext2 is not.


regards
FF

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Alvaro Figueiredo]

Em Terça 29 Abril 2008, Felipe Figueiredo escreveu:
> If you intend to use LVM (which I use both at work, at home, and
> every family/friends computer I put my hands and ubuntu on), the
> FS you choose is an important choice, when it comes the time to
> resize it. IIRC the LVM howto states that ext3 and reiserf need
> to be unmounted to be resized,

To be exact, ext2/3 and reiserfs only need to be unmounted if you
want to shrink it. Both grow on the fly, just like jfs and xfs.

--
Alvaro Figueiredo
[hidden email]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Derek Broughton-2]

Felipe Figueiredo wrote:

> On Tue 29 Apr 2008 20:00:06 Res wrote:
>
>
>> So basically reiser is good for stuff like maildir mail
>> spools, and probably anything else, the only thing I wouldnt run on
>> reiserfs, is databases, because I want rock hard reliance, I want run
>> any
>> journalled FS, so its ext2 only for MySQL's data dir.
>
> Eh, since reiserfs is journaled it should give you the reliance you asked
> for, if journaling is your parameter. Also, ext2 is not.

I _think_ he said he "won't" run a journalled FS because it's unreliable.
That's just plain wrong.  It _may_ not be necessary to put a MySQL database
on a journalled filesystem, because good relational databases do their own
journalling (I _don't_ know if that's true of MySQL).
--
derek


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Rashkae-2]

Res wrote:

> On Tue, 29 Apr 2008, Rashkae wrote:
>
>> ReiserFS is supposed to be the fastest with small files.  I call
>> poppycock on that one.. ReiserFS is only fast in Namesys benchmarks.
>
>
> We have a mailstore, using vpopmail so its maildir, we did comparison
> tests between ext2, ext3 and reiserfs, the same data, as the test box
> grabbed the mail from our nightly rsync backup and sent it to and
> from another dummy server, so we knew it would always be the same data,
> ext2 and ext3 performed the same speedwise, ext3 recovered faster for
> obvious reasons from a deliberate hard power-off, the rsync for ext2 and 3
> took around 1 hour 40mins, for reiserfs the rsync from took 18 mins, and
> send, it took about 1 hour 25 mins, so it has marginal write performance
> but huge read performances,
>

Your test case in this instance is a bit of a fluke... The read
performance for Reiser (and ext3 with dir_index option) is *very*
dependent on the order the files were written in.  If the files get
written to the disk in the same order as the file system hash algorithm
would produce, you get full speed read performance on either system...

Here's an example... configure mutt to store mail in a maidir location.
 then use mutt to copy gigantic quantities of messages into the mail
store. You need to copy enough mail that reading the entire directory
will exhaust your file cache.  You may want to reduce ram for this test.
Once all the mail is written, close mutt.  Now try to use tar to create
a backup of the maidir folder.  You should notice a very slow filesystem
IO, somewhere in the area of 1 to 2 MiB/s.  Once the backup is complete,
delete the maildir, then restore it from your tar file.  Create a tar
backup again... This time, your file IO should be well over 20 MiB/S.

The reason is that the first time, tar stored the files in the same
order as the file system hash order, and when the tar file was restored,
the files got written to disk in that same order as well.  This
performance boost will quickly degrade once you start using the system
however.  XFS and JFS don't suffer near the same performance penalties
and will maintain read performance for the entire directory over time.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users