From: sct@dcs.ed.ac.uk (Stephen Tweedie) Subject: Re: (Q) xia vs. ext2fs Date: Tue, 21 Sep 1993 19:35:53 GMT
Hi,
> Can someone explain the pros/cons of the xia vs. the ext2fs file
> systems?
> I notice that the boot disks seem to be in xia.
> the faq says they both exists but nothing about their +++ & ---.
It's really a matter of personal taste. The HJ boot disks use xiafs
as standard but SLS uses ext2fs. As an ext2fs developer I am
naturally biased towards ext2fs, but they are both perfectly decent
filesystems. All my tests show that ext2fs has a consistent
performance advantage over xiafs, but I have heard reports from other
users who claim xiafs is a little faster. Certainly, neither is much
slower than the other, although I believe ext2fs does suffer less from
long-term fragmentation.
ext2fs has several extra features. It has fast symbolic links, and
backs up superblock information to aid recovery in case of a bad
filesystem crash. It has a more powerful fsck, which is capable of
recovering information after a crash which would be permanently lost
on other filesystems. e2fsck still has a couple of problems in the
case of really severe filesystem corruption, but in these cases most
other fsck's would simply fail to recover any of the lost data at all.
A new, faster and more powerful e2fsck program, as well as a fs
debugger to allow you to manually try to repair ext2fs partitions, are
under development and are now in alpha testing.
ext2fs also supports large sized filesystem blocks, and fragments for
efficient allocation of space should be implemented in the future. I
am working on adding transparent compressed file support to ext2fs.
This is the real difference between ext2fs and xiafs - ext2fs has been
designed to grow.
Under constant use, both ext2fs and xiafs appear to be stable. I know
of only one bug(let) in xiafs, and none in ext2fs right now. There
are some filesystem problems occasionally attributed to xiafs and
ext2fs, but these usually seem to be associated with either the quota
patches (there seems to be some interference between the quota system
and the filesystem unmounting code), and SCSI/Net interactions (it
appears that under very high load, the combined DMA traffic incurred
by running a high-performance SCSI card with DMA networking at the
same time can sometimes cause the system motherboard's refresh cycles
to get delayed to the point where memory corruption can start).
Ultimately, it's up to you... :-)
Cheers,
Stephen.