> In his paper about Foundation Russ Cox explains some circumstances > where you probably don't want venti to archive these files forever. > For these sort of files the services of other file systems are > overkill, too. You don't want write more than one at the same time mostly. > You don't need the ability to append to the file, once it is closed. > If you have files of several Gigabyte size you > probably want to have them contiguous. You cannot use BSD slices or > BSD partitions or plan9 partitions to store these, because there are too few > of them. The 128 partitions on a GPT are sufficient, because a 500GB > disk can be laid out to use one big chunk to host file systems and > several smaller chunks from 1GB to, say 20GB for multimedia files. > Of course, you need utilities to manage these.
there are several styles devices with exactly these limitiations: cd, dvd and bd recorders. the standard data rate for bd disks is 5.4mb/s (en.wikipedia.org/wiki/BluÂray_Disc). venti was easily fast enough to handle this, even on a usb drive. your proposed set of limitations makes no sense to me. venti can stream fast enough and the overhead for storing blocks and not extents is ~1%. further, foundation is an archival strategy, not primary storage. pretty impressive to be able to stream movies directly from the backup. i sure wouldn't give up the ability to store, e.g., an index to which i append an entry each time i add a movie in my moviefs for 1% drop in storage efficiency. since venti goes fast enough, any extra speed is wasted on streaming. > A file system very suitable for this situation was that of DEC's > RT11 (if it were not limited to 16bit block adresses). On this > system, every file was contiguous, there was a directory, which > looked mostly like a big partition table, because the directory had > only one level. A new file could be allocated either with a fixed > size in the 1st gap to fit, or to fill the biggest gap. The default > was to fill the maximum of the 2nd largest gap and half the largest > gap size. 1968 called. it wants its fs technology back. if you must have extents, there are much better (if more complicated) fses that support extents. for example. xfs. i'm not convinced the extra complexity of managing arbitrarly-sized blocks is worth it. - erik
