[OpenAFS-devel] Large-Cache Initialization (Proposal)

[Derek Atkins]

"Todd M. Lewis" <utoddl@email.unc.edu> writes:

> It seems a shame to mess up otherwise good clean working code to
> compensate for a file system that isn't up to the task. Seems like
> switching to ReiserFS, JFS or something along those lines (assuming that
> that would work) would be better -- in this case...

In my experience, _MOST_ file systems aren't up for the task.  Show
my _ANY_ file system that works well creating 3 million files in one
directory.

Also, the simplistic approach I suggested requires no changes to
the kernel code at all.

> On the other hand, if your changes make it easy to spread the cache
> across multiple drives/partitions as well as multiple directories, it
> might be a useful generalization. Clearly it would make life easier for
> people who -- like most of us -- just want stuff to work with what
> they've got.

I'm not convinced this would be as simple.  Indeed, having just looked
at the cache manager code, the code makes the assumption in multiple
places that the cache resides in one and ONLY ONE partition (well, one
filesystem), and keeps a global SuperBlock pointer and uses that to
open the cache inodes.  Changing this would be a MAJOR overhaul to the
system, more work than I'm proposing.

OTOH, creating subdirs within the existing cache partition wouldn't
violate this assumption, as the single superblock for the cache
partition would hold still.  A cache inode in a subdirectory is still
in the same superblock/device.

So, really, I'm just proposing a user-level change to afsd.

> There's my feedback, or what it's worth.

Thanks,

-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