Subject: LFS for databases (was: LFS(?) ioflush/vnlock issues)
To: None <tech-kern@NetBSD.org>
From: Edgar =?iso-8859-1?B?RnXf?= <Edgar.Fuss@bn2.maus.net>
List: tech-kern
Date: 03/10/2007 12:35:02
> IMHO: LFS really isn't suitable for databases - every random
> write operation can fragment the file on disk.
Yes, I'm aware of this. But why would the database file being fragmented hurt performance? You're not going to read from it sequentially anyway, would you?
And with current disc drives, having the file spread all over the disc appears to be no worse than reading non-sequentially from a large file having all of its blocks located in a small region. About half of the average access time is rotational latency, even at 15K, so seeking seems to be not too great an issue.
I'll have a look at read performance, but our problem was write performance and my impression is that LFS is the perfect solution to that. Read performance can be enhanced by varoius cacheing techniques (index files, MySQLs query cache, file system cache/UBC), but write performance can't, as I think. Or am I getting it wrong?