[OpenAFS] Re: Linux tmpfs

[Derek Atkins]

"Chas Williams (CONTRACTOR)" <chas@cmf.nrl.navy.mil> writes:

> In message <5FB03AFA-8CA1-4B39-A743-188E5DBF4666@ece.cmu.edu>,"Brandon S. Allbe
> ry KF8NH" writes:
>>It used to be said (back when warlord was maintaining linux-afs and  
>>Transarc 3.4a was the main release) that the memcache was much less  
>>efficient than the disk cache and that it was better to use disk cache  
>>in a ramdisk.  Both have been pretty thoroughly overhauled since then,  
>>though.
>
> "efficient" isnt meaningful without context.  memcache does use quite
> a bit of host memory.  if your system is short on memory, memcache is
> not for you.  however, memcache outperforms diskcache is most cases
> (ignoring say rereads over a link with high latency).

In this case "efficient" was in terms of memory/space usage.  For the
same memory usage the memcache will be able to hold fewer files
and less file data than a similarly-sized memdisk cache.

> the afs cache is handled by a seperate thread.  the filesystem client
> requests a fetch from the cache manager.  the cache manager does the
> fetch and writes the data into the cache.  it signal the filesystem
> thread all is ready and the filesystem read reads the data.  if you
> use a disk cache this is written to the disk and then read from the
> disk.  memcache speeds this up a bit since you dont have the disk
> latency during this copy.

Yes, it is definitely FASTER to use a memcache.  However it is (was?)
more space efficient to use a ramdisk.

> i thought it might be interesting to make the filesystem thread give
> the cache manager a hint pointer, and the cache manager could memcpy
> the data to the filesystem thread buffers and write it to the disk.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available