ext2 filesystem lockups

[Bruce Evans]

On Wed, 23 Feb 2005, Astrodog wrote:

> On Thu, 24 Feb 2005 01:06:54 +0100, Markus Trippelsdorf
> <markus at trippelsdorf.de> wrote:
> > On Wed, 2005-02-23 at 19:35 -0300, Jo=E3o Carlos Mendes Lu=EDs wrote:
> > > David O'Brien wrote:
> > > > On Wed, Feb 23, 2005 at 04:29:19PM +0100, Markus Trippelsdorf wrote=
:
> > > >>Which filesystem is recommended for multi-OS file exchange?
> > > >
> > > > I've heard enought reports of ext2 problems on 32-bit i386, that I =
don't
> > > > trust it in situations that "have to work".  By far the most widely

I use it with no problems and trust it is easy to fix if some turn up.
I haven't tried it on amd64.

> > > > supported FS is vfat32 [mount_msdosfs(8)].
> > >
> > > The last time I had to use msdosfs, on 4.* it was extremely slow
> > > compared to UFS on the same disk.  Did this get better on 5.*?

The main slownesses in msdosfs are pessimal (random) block allocation
for the first block in a file, and non-use of some important system
features (clustering and VMIO).  This has not been fixed in 5.x AFAIK.

> > I want to use the filesystem for my music collection, so I'm willing to
> > trade fastness for reliability.

ffs is the most reliable of the read-write file systems in FreeBSD.
cd9660 is probably more reliable, and it is most portable, but it is
less convenient since it is read-only in the kernel.  If you only need
to write under one OS then it is fairly safe to use ffs for writing
under FreeBSD and ext2fs for writing under Linux.

> vfat32/MSDOSFS is going to be the most supported, seeing as I can
> mount these types of filesystems on just about every OS out there.
> Regarding speed, there's a pretty big tradeoff, but even if it reduces
> drive I/O by %50, you're still above the speed of a 10/100 NIC, and

A big reduction is 99% :-).  Reductions of 90% are common for small
files.

> certainly above the speed an MP3 streams at. (You're right at the
> limit, for DVD Video) In short, yes, it will be slower, but for the
> purposes of storing MP3s, and whatnot, the speed tradeoff is
> inconsequencial(sp), and it beats loosing everything every once in
> awhile.

But msdosfs is fundamentally very unreliable.  Corrupted FATs give more
global problems than corrupted inodes.  It doesn't help that the msdosfs
implementation cheats with FAT updates and does them fully asynchronously
(delayed up to 30+ seconds) using delayed writes unless you mount with
"-o sync" (which gives sync data too, and thus extreme slowness).  So
msdosfs by default is closer to ffs with "-o async" and thus more
unreliable then necessary.

Bruce