* Volker Kuhlmann; on 22 Jan, 2004 wrote:

...

I suppose it's because they use ACLs. This feature is not supported by reiserfs.

Excuse me? SuSE was the first to have ACL support for all 4 journalling file systems, and has had it for a while now. Since 8.0 I believe.

SuSE linux admin guide for 8.2 (pdf version page 498 "Access Control Lists are a feature of the Linux kernel and are currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS. Using ACLs, complex scenarios can be realized without implementing complex permission models on the application level."

I have always used reiserfs, workstations and servers, and never had a problem. With SuSE kernels though, it's possible that vanilla and redhat kernels are more dodgy wrt reiserfs.

Me too that is why the quesition is raised

When some document says to use ext3 instead of reiserfs for a server, then I suspect the reasons for that are more political than technical.

However the document I made a referance to is the EAL2 certification guide for SuSE SLES8, why would/should SUSE loose its superiority to its competitors. There has to be a technical reason rather tan a poictical one as opinion is not a fact as far as I am concerned -- Togan Muftuoglu | Unofficial SuSE FAQ Maintainer | Please reply to the list; http://susefaq.sf.net | Please don't put me in TO/CC. Nisi defectum, haud refiecendum

SuSE linux admin guide for 8.2 (pdf version page 498

Means it's in 8.2. I'm certain it was at least in 8.1 as well. That manual might not have been updated as fast as the distro.

Since Ext3 can take care of metadata and data itself becomes a winner.

I wouldn't be so fast with that conclusion. How much added data security do ordered writes really provide? What's the performance loss (there has to be one)? If ext3 with data journalling becomes unusably slow it's not a good choice for a server. Use raid 5 instead. Reiserfs does provide the speed.

I've read that ext3 (since it's based on ext2) has been in existence longer than the other filesystems

Not sure, but I suspect it's propaganda. Reiserfs has been usable and reliable on 2.2.x when ext3 was only a test case unsuitable for production. There was reiser from SuSE but not ext3, wonder why. Of course, the fact that reiser was the first available and usable journalling fs for Linux doesn't mean it's still the best now.

so it has been more thoroughly stress tested.

Is this really a plus? Any seriously-sized filesystem extension can screw the lot. Relevant is the total test time of the extension. One has to admire the reiser team though. They have created a new fs from scratch, proving that the deployed technology (contrary to prevailing opinion) not only works but is also fast. Xfs and jfs are adaptations of existing fs to Linux done by companies with oodles of cash. Ext3 was slow off the ground and has probably had more developers than reiser ever had. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.

On Thursday 22 January 2004 16:09, Avtar Gill wrote:

I've read that ext3 (since it's based on ext2) has been in existence longer than the other filesystems so it has been more thoroughly stress tested. Then again there are reports about filesystem corruption with pretty much any filesystem so everyone's mileage will vary regardless.

ext2 has been one of the oldest file systems in the Linux kernel. It is also very small (~5.000 lines of kernel code when I studied it, ~7.000 lines now, Suse Linux kernel sources taken as a reference). reiserfs is much more complex than ext2, though - about 25.000 lines (compare: xfs is ~83.000 lines, ext3 is ~10.000 lines). The difference in size is mostly because of the difference in feature sets - ext2/ext3 is rather primitive compared to reiserfs or xfs, and with ext3 catching up in features it will also catch up in complexity. ext3 is an extension to ext2, and this extension is much younger. In fact, ext3 is pretty much a work in progress - the journalling part now being complete, and other extensions being written right now. reiserfs has been in the kernel longer than ext3 has been, and been in use with Suse Linux kernels even longer. Also, in Suse Linux, reiserfs has been the default filesystem for quite some time now, so one can reasonably expect it to be stress tested in a way comparable to ext2. On recovery and fscking: Both reiserfs and XFS are filesystems with dynamic metadata, while in ext2/ext3, the metadata is preallocated and metadata positions are fixed. That is: in ext2/ext3, you can more or less tell if a block is a metadata block by simply looking at the block number, while in dynamic metadata filesystems you need to look at the actual block contents. That makes work slightly harder for file system checkers. That being said, I can report from personal experience that the reiserfs file system checker is quite good. I had a severe system crash on my system with some hundred megabytes of buffer cache in flight during a major disk space cleanup action. That crash was not related to reiserfs, but a badly configured agpgart, but it corrupted my / and /home partitions beyond simple log rollback nonetheless and I had to reiserfsck both partitions. One partition, /home, even needed a complete rebuild check. reiserfsck did this, and in a very successful way. It read all data blocks of the partition and identified metadata by inspecting magic bytes in each block. From the metadata blocks it identified, it rebuilt the complete filesystem structure and recovered all data blocks. The filesystem is now online again, and with very minimal data loss. In fact, reiserfsck was a bit more successful than I expected. I had several vmware vmdk files on /home which also contained reiserfs filesystems inside. reiserfsck identified metadata signatures in these blocks and tried to link the contents of these files into the main filesystem. In doing to it discovered that this would lead to a crosslinked structure (blocks being metadata- and data-blocks at the same time, and blocks referenced twite),sucessfully duplicated these blocks, and relinked the duplicated structures under lost+found. I ended up with some 1.2 GB contents from inside the vmdk files properly duplicated, reconstructed and relinked under lost+found, which I simply deleted, and all was well. Kristian