Actually, as said before I think a storage model can be found that does not
penalize small objects, mostly eleminating the need of that ramdisk, instead
allowing the ram to be used for proper hot object caching.
The more I think of these issues, the more appealed I am by my old "multi
level cyclic filesystem" idea, which basically is a log log structured file
system with metadata optimized for log structures and the voilatility of a
cache, and log cleaners at various time intervals of the log. Such a system
can be made to operate close to the I/O bandwidth of modern drives. Certainly
so for writes, and with some intelligent data ordering and prefetching reads
can also be improved a lot. Maybe not in Polygraph testing, but quite
likely in real life.. not sure how realistic model for locality of reference
Polymix-4 represents. The nature of log cleaning also allows one to use idle
time to improve hit rate and to increase performance during peak usage.
With the COSS approach and segment based space recycling one can acheive
similar results (not too unexpected as the basic ideas is the same), or
perhaps even slightly better from a I/O perspective as there is less meta
data, but at a higher penalty in memory usage and hit rate. The beauty of
coss is simplicity as it mainly needs to care about data, not metadata.
In-memory metadata is wastly simpler to deal with than any on-disk
equivalence.
Regards
Henrik
On Wednesday 21 November 2001 20.57, Joe Cooper wrote:
> More tuning is needed on the RAM disk+hard disk balance. But with RAM
> prices being what they are, I'm definitely going to work on it some
> more. It might allow us to get into the networks where the money is
> (and the only networks that are still coming online in the US--small
> ISPs are becoming a thing of the past here). We need at least 48Mbits
> uplink support from a single reasonable sized box to get into those
> markets...we're getting closer (22Mbits is our largest machine in
> service and it's sweating most of the day), but still not there.
Received on Wed Nov 21 2001 - 14:19:55 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:38 MST