On Mon, Dec 16, 2002 at 01:13:29PM -0800, Rod Van Meter wrote:
> Let me get this straight, just to be sure (probably others are wanting
> the same info, anyway):
> 
> Client:
> file cache in /usr/coda: ext3 okay since 2.4.10 kernel, okay in new
> 2.5.x

ext3 okay since 2.4.10, but some other small things (mmap the same file
by multiple processes, etc) got resolved as late as 2.4.19.

> Server:
> log partition/file: raw partition preferred, ext2 okay, ext3 NOT okay?
> data partition/file: raw partition preferred, ext2 okay, ext3 ?
> file data partition: ext3 okay, ext2 okay

Doesn't matter whether it is RVM log, RVM data or file data.

Know to work just fine
ext2, ext3, reiserfs, ramfs, tmpfs, probably even jffs2

probably ok,
jfs, ntfs, xfs

probably _not_ ok.
adfs, affs, bfs, cramfs, efs, msdos, vfat, hfs, hpfs, intermezzo, isofs,
minix, ncpfs, romfs, smbfs, sysv, udf, ufs, umsdos

These filesystems are either readonly, don't support mmap, or are
networked, or I simply don't know enough about them.

btw. this list is for Linux only, f.i. ufs will work just fine on a BSD
machine.

Also there is a tradeoff when using raw partitions versus a filesystem
for RVM log and data. We cannot mmap a raw partition, so RVM copies the
complete data partition into a large allocated chunk of memory during
startup. This causes a lot of VM trashing when RVM is larger than
physical memory. When a file is used, we can set up a private mapping
and parts of the data file are paged in when necessary.

However writing to a raw partition is slightly faster compared to
writing to a file in a filesystem. Also because RVM essentially keeps
track of it's own modification log in the RVM log file/partition, using
ext3, reiserfs or JFS doesn't improve recoverability, but does make
writes significantly slower because of the journaling performed by the
filesystem.

Jan