reiserfs, xfs, ext2, ext3

Hi,

We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to come so we can change our proxy server, that will run on Linux with Squid. One disk will go inside (I think?) and the other 4 on a tower conected to the RAID, which will be have the cache of the squid server.

One of my partners thinks that we should use reiserfs on all the server (the partitions of the Linux distro, and the cache partitions), and I found out that reiserfs has had lots of bugs, and is marked as experimental in kernel 2.4.4. Not to mention that the people of RH discourage there users from using it.

There has also been lots of talks about reiserfs being the cause of some data lose and performance lose (not sure about this last one).

So what I want is to know which is the status of this 3 journaling FS. Which is the one we should look for?

I think that the data lose is not significant in a proxy cache, if the FS is really fast, as is said reiserfs is.

Saludos... :-)

El mejor sistema operativo es aquel que te da de comer.
Cuida tu dieta.
-----------------------------------------------------------------
Martin Marques                  |        [email protected]
Programador, Administrador      |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------

that's a pretty huge cache, have you considered using 8*9gb disks instead of 4*18? what sort of request throughput/latency are you aiming for? as the number of requests grows, disk seek times are a very real problem.

well, lots of bugs in reiserfs have been fixed.. obviously there are more bugs to come (as always), but on the whole a lot of people are very happy with it. there certainly haven't been many posts of reiserfs corruption lately at all on linux-kernel.

they do?

xfs, while wonderful, probably isn't what you're looking for. AFAIK it is intended more for very very very large files.

data loss is always significant. consider the case where you are forced to rebuild the filesystem squid's cache directories reside on... admittedly it is an extreme case, but it is a possibility all the same.

reiserfs is supposed to be very good with lots of small files, which is the typical case for a squid cache. however there's no substitute for actual testing. benchmark your squid server (use polygraph, from the squid website) with each fs, and remember to test each of squid's cache_dir options (diskd, aufs, coffs, ufs).

also appropriate could be ext2 with daniel phillips' directory indexing patches.

test. test. test. good luck.

j.

"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

At the time Red Hat 7.1 was mastered Reiserfs was not stable. The reiserfs in the RH kernel has some of the tail fixes but newer ones are not present. Also it had other problems then: the fsck tool was useless, it didnt work on big endian machines (eg PPC, S/390).

If Hans sent me a patch removing the experimental tag from Reiserfs the only thing that would make me hesitate the slightest from applying it would be the endianness thing, and thats not enough to stop it being applied.

If you are running 2.4.4/2.4.4-ac/2.4.5pre I believe all the relevant reiserfs patches are applied. The new fsck seems to work a lot better too. The limiters right now are:
- You need a patch for NFS (its on their site no big deal)
- You can only use little endian boxes (x86 for you so ok)

reiserfs seems to handle large amounts of small files well, up to a point but it also seems to degrade over time. ext3 isnt generally available for 2.4 but is proving very solid on 2.2 and has good fsck tools. Ext3 does not add anything over ext2 in terms of large directories of files and other ext2 performance limits.

XFS is very fast most of the time (deleting a file is sooooo slow its like using old BSD systems). Im not familiar enough with its behaviour under Linux yet.

What you might want to do is to make a partition for 'mystery journalling fs' and benchmark a bit.

Alan

Jeff Mahoney has a patch in progress for this, he currently has the kernel code working, but needs to do the utilities. I would hesitate to put the endianness fixes in before 2.5.1 just because I am conservative about disturbing stable code.

There exists one known bug which one user has hit which required a major code change to fix. We are now testing the code, and are in the ironic situation of hesitating to merge in a bug fix out of fear that the bugfix code is large and untested, and it might have bugs that more than one user will hit.:-/ I think we are going to make the new code an option until it has been extensively tested.

I think that 2.4.4 is stable, and I say this based upon us getting lots of users with
hardware bugs and none with bugs not fixed in 2.4.4 in the entire time since 2.4.4 was released.

you also need a patch for quotas.

you can ask nikita for a copy of reiserfs_raw, a version of reiserfs designed for squid. It is substantially faster.

Hans

I have a proxy server that's been running 2.4.3pre4 with reiserfs for the partitions on the cache disks. it has an uptime of 43 days at this point. it wasn't very stable at all (two crashes in one week) with 2.4.2. I'll be building 2.4.4 something when I get back from ghana to the US, but I don't want to reboot it onto a fresh kernel while I'm 11,000 miles away, serial console notwithstanding.

Overall I'm of the belief that reiserfs is robust enough for mainstream use, and it's significantly faster than ext2 for the squid box, you do as usal need to be a bit selective about what kernel you choose to run.

--------------------------------------------------------------------------
Joel Jaeggli				       [email protected]
Academic User Services			     [email protected]
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

In linux-kernel, [email protected] wrote:

:  We are waiting for a server with dual PIII, RAID 1,0 and 5 18Gb scsi disks to 
:  come so we can change our proxy server, that will run on Linux with Squid. 
:  One disk will go inside (I think?) and the other 4 on a tower conected to the 
:  RAID, which will be have the cache of the squid server.

Reiser is not good idea for squid cache. Why ? Squids cache is hashed by default to minimize "big directory effect". Reiserfs is fast on realy big directories, but it eat more cpu than ext2. On high loaded cache servers cpu utilization on reiser can be realy big. Better way is make more subdirectories in squid cache, and use filesystem, that eat less of cpu.

Daniel Podlejski <[email protected]>
   ... I am immortal, I have inside me blood of kings,
   I have no rival, No man can bemy equal ...

Nice theory, but the benchmarks say the opposite. Turn off tails, use reiserfs raw, and we are the fastest way to do squid, which is still way slower than the proprietary solutions that don't use squid. (squid's user space architecture is poorly threaded, and that becomes the bottleneck.)

Hans

Hmm, I just removed 2.2 Gbytes of data in 30000 files in 37 seconds (14.4 seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu linux box with a not very exciting scsi drive.

I agree with Alan here, the only sure fire way to find out which filesystem will work best for your application is to try it out. I have found reiserfs to be very fast in some tests, especially those operating on lots of small files, but contrary to some peoples, belief XFS is good for a lot more than just messing with Gbyte long data files.

Steve Lord

XFS used to have the performance problems that Alan described but fixed them in the linux port, yes?

Hans

Hmm, we do things somewhat differently on linux, but I suspect most of it is due to hardware getting faster underneath us.

Steve

[...]

The ext2 indexing patch is apparently stable but it's still pre-alpha until the hash function is finalized. I could see using it to run performance tests of ext2+indexing against the alternatives, but only if you are prepared to rerun mke2fs later. Then there is the matter of making fsck index-aware. As it stands now, if fsck finds an index it will remove it.

But by all means please test the patch:

http://nl.linux.org/~phillips/htree/dx.testme-2.4.4-4

It would be great to see a table of ReiserFS/XFS/Ext2+index performance results. Well, to make it really fair it should be Ext3+index so I'd better add 'backport the patch to 2.2' or 'bug Stephen and friends to hurry up' to my to-do list.

--
Daniel

Is the IBM JFS at a testable state yet, or is it still 'bleedin beta'?

-Dan

It is not stable enough to use in production yet. It is certainly stable enough to test/benchmark. They released a new patch today which is supposed to fix a long standing deadlock, so thats good news. Give it a shot.

Jim

Actually, I would think e2fsck will simply refuse to run if the COMPAT flag is set...

Actually, Andrew Morton has a nearly working ext3 implementation for 2.4. It is at the stage where it works most of the time, but we are not yet sure that everything that needs to be journaled is.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

If you worry about that, put the squid cache in a fs
of its own. If it ever dies - use mkfs and restart with an empty cache. No need to spend a long time fsck'ing something with a limited lifetime that can be re-fetched.

Helge Hafting

I never experienced ReiserFS data loss, but I did experience read performance loss over ext2fs and switched that file system back to ext2. The ReiserFS people could not reproduce the problem, so I'm not sure what was the actual cause.

ext3fs has never given me any problems, but I did not have it in production use where I discovered major ReiserFS <-> kNFSd incompatibilities. ext3 has a 0.0.x version number which suggests it's not meant for production use.

XFS is claimed to work with NFS, but not currently availabe for Linux 2.4.4.

JFS has some showstopper bugs that would prevent me from using it.

If you're deploying a cache partition such as /var/squid (possibly having log files in another /var/log partition on another disk drive), what's the point about not running (e. g.) mke2fs and squid -z on boot, as well as mounting the system partitions (/usr) read-only (prevents fsck on next reboot)? mke2fs is faster than reiserfs recovery probably ;-)

On one not very scientific test: unpacking and deleting a cache hot 40MB/230MB gzipped/unzipped tar on ext2 and xfs on a IDE drive on a lowend SMP box.

XFS (very recent 2.4.4 CVS, filesystem created with mkxfs defaults)

real    1m58.125s
user    0m16.410s
sys     0m44.350s

real    0m50.344s
user    0m0.190s
sys     0m13.950s

ext2 (on same kernel as above)

real    1m26.126s
user    0m16.100s
sys     0m36.080s

real    0m1.085s
user    0m0.160s
sys     0m0.930s

ext2 seems to be faster and the difference on deletion is dramatic, so at least here it looks like Alan's statement is true.

The test did not involve very large files, the biggest files in the tar are a few hundred K with most of them being much smaller.

The values stay similar over multiple runs. I did not do any comparisons recently with reiserfs, but at least in the past reiserfs usually came out ahead of ext2 for similar tests (especially being much faster for deletion)

-Andi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Just to pick up on this thread, to operate the JANET Web Cache Service (proxy caching thingy used by a lot of ac.uk folk) we currently run Squid on top of 2.2.18 + Linux Virtual Server 1.0.5 + ReiserFS 3.5.31 and the Magic-SysRq-over-serial-console patch.

In almost a year of operation (admittedly covering a couple of earlier kernel/ReiserFS/... combos, and gradually migrated to our 40-odd cache servers) we've only ever had a couple of wibbles which directly implicated ReiserFS - and these on servers which later turned out to have hardware problems. Lockups on the older 3c905 and eepro100 drivers have caused us some problems historically, though.

As the JANET backbone has migrated to 2.5Gbit/s we've seen our daily transaction rate rise to over 100m URLs, with one peak of 120m. Moving our cache filesystems from ext2 to ReiserFS almost tripled the number of requests we could process per second before a cache box became overloaded, and our fastest machines (6 x 10,000 RPM Ultra160 SCSI cache disks) are now shipping some 230 requests/s with around 50ms latency for a cache hit.

FWIW, we're currently using Squid 2.2.STABLE5-hno.20000202 and using ReiserFS as a regular filesystem rather than raw, so there ought to be quite a bit of scope for improvement. Commercial caching systems have demonstrated thoughput of thousands of requests/s with similar hardware, but I suspect Tux-ification of Squid will be necessary to catch up with them. This (in the form of our old chum the proprietary loadable kernel module :-) seems to be the direction the commercial vendors are going in to get maximal performance out of their Linux ports...

Cheers,

Martin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin

iD8DBQE6+pQyVw+hz3xBJfQRApYsAKCuy1yPe/KarPluSeTB6OKgmfQ+8wCfYPi2 li9nQT05bhlj7Us3fXf3+l8=
=biJi
-----END PGP SIGNATURE-----

Hmm... Reiserfs is incompatible with knfsd? That might explain the massive data loss I was getting with reiserfs (basically I'd have to reformat and reinstall every couple of weeks). The machine this was happening with also exports my apt cache for the rest of the network.

Tony

Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

[email protected]

On 05/10, Matthias Andree rearranged the electrons to read:

$ uname -r
2.4.4-ac5.xfs
$ uptime
  9:20am  up 1 day, 18:28,  4 users,  load average: 0.00, 0.00, 0.00

--
Hob Goblin
[email protected]

A society that will trade a little liberty for a little order will lose both and deserve neither. - Thomas Jefferson

not at all, search for X15 in april/may linux-kernel archives. most of the specific improvements tux made have been reduced to improvements for the general case, hence squid (or equivalent) could probably improve a fair amount.

j.

"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

For that particular application of squid, it happens we are much much faster than ext2, if you apply all the right tunings and especially if you apply the reiserfs_raw patch.

Hans

we have a patch on our website.

Hans

squid needs a deep rewrite, and the sponsor for our doing that is flaking regarding sending us money, so for now I have to say to people that even though reiserfs is faster for squid than ext2, the bottleneck is squid not reiserfs, and you really should use the proprietary stuff because the proprietary guys have taken squid, rewritten its engine which is badly designed, stolen the gpl code, and nobody is suing them for it and they are so much faster than squid that the cost of the software is worth paying for (unless you dislike stolen gpl code:-(, and even then there are some like Novell that didn't steal from squid and are faster).

Hans

ANNOUNCEMENT: New Linux port.

Announcing the heaviest Linux machine available. The port of Linux to the ENIAC is the next step in open source productivity and may be the most important invention in the world. Since it is so difficult to find a modern operating system for the world class ENIAC system, ENIAC Linux will present you an entirely new world.

There were only a few problems with Linux and ENIAC--The smallest Linux kernel is still a hundreds of thousands bytes. In order to work around this small detail, we have stripped Linux of all the unnecessary subsystems. Now, after removing the SCSI, PCI, IDE, Memory, NET, USB, Printing, Processes and Scheduling subsystems, ENIAC Linux is also the world's smallest Linux. Since ENIAC lacks online storage, ENIAC Linux uses a sophisticated paper diagram to to minimize storage requirements and improve wiring speed.

With all these improvements, however, Linux ENIAC is still a very buggy system. We are constantly replacing buggy and burnt-out pieces of the ENIAC Linux machine. We hope that the next-generation EDSAC, with a reduction in size by 16,000 tubes and new memory technology, will improve the responsiveness, effectiveness and reliability of the Linux port to the ENIAC architecture.

Wasn't it EDVAC IIRC?

-mirabilos

EA F0 FF 00 F0 #$@%CARRIER LOST

Could you give un information on the hardware you're using for that proxy?

Saludos... :-)

El mejor sistema operativo es aquel que te da de comer.
Cuida tu dieta.
-----------------------------------------------------------------
Martin Marques                  |        [email protected]
Programador, Administrador      |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------

On Thu, May 10, 2001 at 01:44:53PM +0200, Matthias Andree wrote:
[snip]

A while ago I configured a few squid boxes which ran off of a read-only system. Mke2fs is actually unacceptably slow on large file systems, faster then fsck, but still time consuming. I found that zeroing out the disk, then formating it and saving the non-zero blocks, replaying them on reboot to be an acceptable solution.

On linux-kernel, [email protected] (Andi Kleen) wrote:
: On one not very scientific test: unpacking and deleting a cache hot 40MB/230MB : gzipped/unzipped tar on ext2 and xfs on a IDE drive on a lowend SMP box. :
: XFS (very recent 2.4.4 CVS, filesystem created with mkxfs defaults) :
: > time tar xzf ~ak/src.tgz

:  real    1m58.125s
:  user    0m16.410s
:  sys     0m44.350s
: > time rm -rf src/
:  real    0m50.344s
:  user    0m0.190s
:  sys     0m13.950s

:
: ext2 (on same kernel as above)
:
: > time tar xzf ~ak/src.tgz
:

:  real    1m26.126s
:  user    0m16.100s
:  sys     0m36.080s
:  
: > time rm -rf src/
:  
:  real    0m1.085s
:  user    0m0.160s
:  sys     0m0.930s

And another test:

ext2:

root@witch:/mobile:# time tar xzf /arc/test.tar.gz

real    5m25.249s
user    1m33.430s
sys     0m31.710s

root@witch:/mobile:# time rm -rf test/

real    0m8.843s
user    0m0.000s
sys     0m0.420s

xfs:

root@witch:/mobile:# time tar xzf /arc/test.tar.gz

real    5m23.744s
user    1m34.800s
sys     0m39.100s
root@witch:/mobile:# time rm -rf test/

real    0m1.364s
user    0m0.030s
sys     0m0.430s

test.tar.gz is tree created by script:

#!/bin/bash

for lev1 in aa bb cc dd ee ff gg hh ii jj kk ll
do

	mkdir $lev1
	cd $lev1

	for lev2 in 0 1 2 3 4 5 6 7
	do
		mkdir $lev2
		cd $lev2

		for fname in a b c d e f g h i
		do
			dd if=/dev/urandom of=$fname bs=4k count=1024
		done

		cd ..
	done

	cd ..

done

Daniel Podlejski <[email protected]>
   ... When you're talkin to yourself and nobody's home
   You can fool yourself, you came in this world alone ...

You're not getting data loss, but access denied, when hitting incompatibilities, and it looks like it hits 2.2 hard while 2.4 is less of a problem. Please search the reiserfs list archives for details. vs-13048 is a good search term, I believe.

I'm always wondering why the patch hasn't been merged. Is it so dangerous to apply in that it might distract other pieces of the system? Has anyone reported increased problems after applying the patch?

Matthias Andree

It requires explicit changes to each filesystem that wants to work over NFS, and is a somewhat large change.

-chris

Data is lost:

Root can't access the files.
Reiserfsck can't repair the files.
The files that are corrupted are unrelated to the ones exported over NFS (which makes me wonder if it's the same bug).

File corruption would begin a couple of hours after the volume was formatted, and become catastrophic within a couple of days.

Until the fix is merged I'm not going within 100 miles of reiserfs!

Tony

Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

[email protected]

Come on, we got zerocopy TCP pushed into a stable kernel release with the words "get over it".

So please, push this patch to Linus; I really like to "get over it".

I think with the growing acceptance of ReiserFS in the Linux community, it is tiresome to have to apply a patch again and again just to get working NFS. 2.2 NFS horrors all over again.

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

there is a patch, it is on our website, what is the problem?

That's not true, at least not in my case. Data is temporarily inaccessible, and in extreme cases, the Kernel might panic, but I never suffered from permanent damage. There might be other reasons, old kernel, old patch, old user-space utilities, hardware flaws. I'm not a good friend of ReiserFS on Linux 2.2 in production, but let's please keep honest, regardless of how big the anger may have grown.

True, catches EACCES.

Also true, because they're not broken.

It's probably not. vs-13048 can usually be rectified (ugly, slow but usually works on machines even with 256 MB RAM and 1/2 GB swap) by ls -laR / or treescan -stat /.

Well, it would be really a good idea to consider if the patch might be merged into ReiserFS 3.5.33, but AFAICS, the ReiserFS team have focused on getting 3.6 solid. Hans, does ReiserFS 3.6 suffer from vs-13048 or similar problems with NFS in plain Linux 2.4.4 or does ist still need patches as 3.5.x does?

The zero copy patches were basically self contained and tested for 6 months. The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel. There is a difference.

Alan

nikita, ask Neil what the timeline is for it going into Linux.

Hans

ls can't access the files either, so I don't see how that could rectify anything. The entire directory becomes inaccessible. This happened to /lib once. Nasty.

I'd like to be able to use something like reiserfs, especially when developing (it reduces boot time a lot). However to call it 'stable' on 2.4.4 is simply wrong. If/when the nfs fix gets merged and tested *then* it stands a chance of being called stable.

Tony

Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

[email protected]

No-one can access the files once the caches are hosed. Purge the inode/dentry caches and retry.

Does that actually apply to 2.4.4 or rather to 2.2.19?

Are you referring to Neil Brown's nfs operations patch as being as ugly as hell, or something else? Just want to understand what you are saying before arguing.....

NFS is ugly as hell, and we just try to conform to whatever is the latest trend expected to be accepted since I really don't care so long as it works and doesn't uglify ReiserFS more than necessary. If you have another approach, one that is less ugly, please let us know. This is the first I have heard someone complain, I thought his patch was liked by Linus architecturally and that it would be going in sometime real soon now (which is why we coded for it). Can you articulate why you dislike it in more detail?

Hans

Andi has sent me some stuff to look at. He listed four implementations and I've only seen two of them

Oh believe me we agree in great detail where the -problem- is. Unfortunately the spec is kind of stuck. Its finding a minimally invasive solution for 2.4 pending fixing it properly in 2.5

Alan

did you see an implementation which adds operations to VFS and is written by Neil Brown (with reiserfs portions by Chris and Nikita)?

Tell us what to code for, and so long as it doesn't involve looking up files by their 32 bit inode numbers we'll probably be happy to code to it. The Neil Brown stuff is already coded for though.

Hans

Next time around, when you update the on-disk format, how about allowing for such a thing?

You could have a tree that maps from inode number to whatever you need to find a file. This shouldn't affect much more than file creation and deletion. Maybe it will allow for a more robust fsck as well, helping to justify the cost.

It would be really nice to be able to find all filenames that refer to a given inode number.

Does NFS server support for one of the included FSes not belong in the kernel? or is it that a better way is possible and this ugly one should not be included? If the latter, has anyone told Hans how to do it 'right' so he can assign someone to the task?

The patch Andi forwarded me for NFS still isnt too great but it meets the requirements in that it doesnt touch non reiserfs file systems and its fairly easy to verify that the NFS code paths are not changed for other file systems

inode numbers have in the past been enough to find the object in the filesystem, and more than a few applications have counted on this. In my mind, the difference between an interesting research project and a real professional grade product is compatibility with these kinds of traditional expectations.

I think reiserfs has been lucky that we've managed to work around the inode number problem so far (with help from Neil, Andi and others), but the number of hours wasted on cramming the 64bit key into various applications has been huge.

It only makes a speed difference because the original format relies on it. When redoing the format for v4, this kind of thing should at least be considered. </soapbox>

-chris

It would have a significant performance impact and use disk space.

Hans

I coded up a mixture of Andi's 2.2.x apis and Neil's 2.4.x stuff and sent it out for review a little while ago. It isn't as good as Neil's stuff, but it doesn't require changing the other filesystems. If it looked good to the NFS guys and the other FS guys don't hate it, I'll push it around for testing/inclusion.

This would be my preferred solution right now, since it could also work for AFS.

-chris

Hello

We've installed reiserfs on a logical volume, consisting of 2 60GB hard drives, and exported it over NFS. Kernel 2.4.6-pre3. In the beginning everything seemed to be fine. But then a few strange things have happened:

1. I tried running a program on a host, importing the filesystem in question, and sending its output to it. The program uses fwrite function, and checks the number of items written, so, it didn't match. On the second run yet another (similar writing) problem occured, but since then this program has been running for a few hours already without any noticeable errors. The remote host is Solaris-2.7 on a Sparc.

2. Another strangeness - this filesystem is also mounted on yet another Linux machine, running 2.4.5. Actually, the situation is slightly more
complicated: on host a we've got 2 logical volumes with reiserfs: a1 and a2, mounted in /mnt/lvm/a1 and /mnt/lvm/a2. And the whole directory /mnt/lvm is exported over NFS. So, when on a remote host you do df -k on that mounted filesystem, all 3 values (total, occupied, free) are wrong.

3. All (except ext2, which is used for /) filesystems are compiled as modules. reiserfs is loaded on boot, when lvols are mounted. I tried mounting a fat-diskette, and got the following mesage:

read_old_super_block: try to find super block in old location
read_old_super_block: can't find a reiserfs filesystem on dev 02:00.

If all the problems, mentioned above are known and have known solutions (patches, etc, however, I checked the reiserfs ftp-site - no patches for 2.4.6 yet), please let me know. Shall I use an earlier kernel version? If they are new, I'll gladly provide any necessary additional information. Below is lspci output:

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 50) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 7a)

Thanks
Guennadi
___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, Sheffield, U.K.
email: [email protected]