[OpenAFS] Re: Linux tmpfs

Derek Atkins warlord@MIT.EDU
Fri, 14 Nov 2008 07:47:57 -0500

"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,  
> "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 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