I am going back now and fixing a few bugs, namely MKISOFS and IOZONE for
NWFS. I've also added calls to generic_file_read, bmap, and readpage
for 2.2.16 as well as 2.4 and 2.0.38. MKISOFS turned out to be a
GLIB/POSIX bug in the way that MKISOFS interacts while using readdir()
-- it still has some problems with NCPFS, SMBFS, etc. but NWFS works
now. At any rate, the obvious solution for me here is to create a
"virtual" directory file for each directory in my directory asssign
hash, which was needed anyway to complete the salvageable file system,
so this turned out to be a very useful exercise. But on to the main
point.
While fixing the deadlocks in IOZONE (thanks to Al Viro, this is now
fixed -- removing the locks from create.c really sped things up and got
rid of most of the deadlocks that were remaining), I noticed **DISMALL**
read performance running IOZONE after I converted from the NWFS LRU to
Linus' Page Cache interface in 2.2.16 with generic_read_file(),
readpage(), etc. so that NWFS can support fully memory mapped files
(Andi Klein -- this one's for you). Performance for writes to a file is
on par with EXT2 and EXT3, however, reads really suck wind with this
test with NWFS if I use generic_read_file(). EXT2 is getting @
24,000,000 bytes/second while NWFS is only getting 4,000,000
bytes/second running the same test through the page cache. Writes
perform identically to EXT2 (2,000,000 bytes/second) which would
indicate I am hitting I/O limits for the box (dual processor PPro 200
Mhz System).
Is there a penalty for being deviceless vs. device file systems on the
VFS? It looks like I am hitting an artificial barrier. When I use the
NWFS LRU for reads, I get 26,000,000 bytes/second as opposed to
4,000,000 bytes/second compared with the 2.2.16 page cache with
generic_read_file(). I would rather use Linus's page cache since if I
do, all the mmap user space stuff works correctly. I also noticed that
smap() exists in the fat FS's but nowhere else. I am assuming I don't
need smap() for mmap support.
Please advise.
:-)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:26 EST