(Illustration by Gaich Muramatsu)
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. JanReceived on 2002-12-16 16:42:50