>Not to confuse matters even more, but it's somewhat >of an oversimplification to say "V7 / BSD / UFS" >filesystem and to condemn their performance in >two sentences. For additional reading material, one might want to look at the recent Usenix proceedings, Winter '93 and Summer '93 both had some interesting file system papers in them. There were several papers on LFS (Log Structured File systems) including transparent file migration (I think most of them were in Summer '93). There was at least one new paper about the 4.4 FFS improvements (sometimes refer ed to as EFFS or Clustered FFS (but not in the paper!)), and how the dramarically improved performance beats out LFS in almost all cases. (I still *like* LFS, but have to admit that to beat EFFS you need either a somewhat contrived situation, or enough need for "fast fsck, no file system damage" that you wouldn't want to trust code as new as LFS to do it!) [...] >So far as "sparse files" goes, it's not really much of >a surprise AFS doesn't do a very good job with them. >It's really quite simple: the most popular use of "sparse files" >is with database packages such as "dbm". One might want to >use such a database from either a single machine, or from >multiple machines. The single-machine case will obviously >benefit from storing it on the local disk. If use of the >database involves any amount of writing, it's necessary to do >locking, and there are all sorts of bad things about network >locks - which means they perform, at best, not nearly as well >as locks based purely on the local machine. Only in the case >where the database changes rarely does it make sense to store >a file out on the network, in which case, it's often simplier to >write out a "packed" database. Simply by looking at how files are >used in Unix, it's easy to conclude that sparse files should be a >pretty low priority in any network filesystem, so it's not much of >a surprise they just don't work right in AFS. The primary use of .dbm (and .db) files at several places I have worked is as an index, all updates were done on a single machine (each file had a machine that would update it, not all files were kept up to date by the same machine!!), and normally they were done by copying the .db file, modifying the new copy, and atomicly moving it onto the old copy. This should be network safe (it isn't on NFS - "stale filehandle" errors can happen, but with a few cover functions that re-open the file on such errors it's Ok). It should be something that we can do well over AFS. (fortunately the libdb stuff doesn't create files with very many holes, at least not when instructed to make B-Trees). -- Not speaking for UUNET Technologies
