Re: [squid-users] Ramdisks

On 22 Nov 2001, at 3:02, Henrik Nordstrom <hno@marasystems.com> wrote:

> On Thursday 22 November 2001 01.04, Joe Cooper wrote:
>
> > Let me see if I get what you're pointing at by the term 'log structured':
> >
> log structured == the storage space is viewed as an virtually infinite sized
> sequential log. Any changes to the filesystem is stored in the tail of the
> log. Active portions of this virtual log is then mapped to your actual
> storage media.

> So now you may thing that this log model where space is reclaimed in the tail
> reduces the cache policy to FIFO. This is correct. However, there are some
> hacks one can do to approach a LRU policy, and combined with the fact that
> drives are growing in size faster than in speed this issue is getting less of
> an issue by time..

 I think you are too conservative here. Disk size and sequential speed are
 well related and growing both. The technique you name as hack is actually
 very well suited to log-FS (basically copying any read-accessed data to
 the write buffers and eventually writing them out again together with other
 write data, at FIFO tail, reaching pure LRU), and has almost zero performance
 impact. Disk IO performance is limited by seek/rotational latency mostly,
 and copy of cache-hits only increases write sizes about 20-30% (byte hit
 ratio). With log-FS disk-io performance is limited by random reads, not
 writes. And this difference is pretty large and growing.
 So this is imo very decent approach and not a hack at all.

> > The writer threads order object writes to fill in expired spots on the
> > disk near where the reader threads are going to be acting next.
>
> Such optimizations of block allocation can be applied, provided there is free
> disk space nearby. But it is often better to keep the writes more ordered to
> avoid excessive fragmentation of the storage media. The penalty is relatively
> low as that single physical write operation contains hundreds if not more
> filesystem operations..

 Major idea of FIFO-like FS-es is to make sure writes are sequential to
 disks always. Reverting to random writes to fill expired spots defeats
 that performance benefit. Trying to be more smart in disk allocation
 and keeping write chunks large forces us to make compromises between
 fragmentation, removal policy hitrate and performance penalty.
 At a cost of disk space we could do alot, but I don't believe that
 increasing disk sizes are the cure. Its never been that consumer disks
 are left unfilled, and I don't think this is gonna change any soon ;)

> > True. I like the idea of COSS for a lot of reasons...And I'm doubtful
> > that any more traditional FS type could do better for small objects.
> > The ideal balance, I expect, will be from the following layout:
> >
> > A real hot object memory cache with lazy flushes to -> disk I/O layer
> >
> > Disk I/O then selects either COSS or a more traditional FS based on
> > object size (small objects go to COSS, while big objects feed into a UFS
> > or logged FS).
>
> Or COSS is fixed to also be able to deal with large objects.. and you only
> use COSS..

 I would probably resist that idea. 80% of requests are small. Forcing
 COSS to deal with large objects we clutter it with needless complexity
 that hits the performance eventually, and probably also at a cost of
 higher ram usage. For large objects better use FS thats best suited for
 large objects or at least adds least cpu overhead. I'd rather welcome
 another COSS-liks fs implementation optimised for large files if there
 is a need for such approach. Highest req/rate path should be very
 optimised.

 I feel it's so common that people try to reach a universal FS that is
 optimal for all cases. IMO we shouldn't even attempt that.

> But there may be gains from a policy point in separating large and small
> objects from each other. It is quite likely one wants to apply another
> storage and removal policy to large objects than to small ones.. i.e. store
> them on larger and cheaper media, and keep them longer as the benefit from a
> single large hit is quite large at a low operation cost, but less frequent.

 Definitely, definitely. Logical removal policy for small objects is
 LRU or LFU, optimising object hit-ratio, for large objects you would
 prefer optimising byte hit-ratio. Imagine tape-drive robot and some
 huuuge files ;)

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Thu Nov 22 2001 - 04:25:43 MST