Possible use for memcache?

[Ivan Krstic]

mike wrote:
> However, I think I've figured out a way that might work; basically
> using the memcache idea of hashing the requests to identify which
> server is serving the data could alleviate any issues with NFS not
> being "globally" aware

Can you actually explain what you're trying to accomplish? High
availability via NFS server failover? Increased performance via multiple
NFS servers serving the same physical storage? Both? Something else
entirely?

> If someone could write an NFS client using FUSE (perhaps?) and have it

FUSE is Linux-only.

> Basically any time the FS would need
> to issue or check a file lock, it would hit the memcache API to check
> if it's been locked or "represented" yet by a specific NFS server.

Getting all the LOOKUP/translate handle/cache handle/avoid ESTALE
semantics right would probably be a complicated, error-prone, tricky,
and slow mess, particularly for someone not well versed in the subject
matter.

NFS talks about files in terms of opaque binary filehandles which are
server-specific; you'd need to do all sorts of extra bookkeeping and
synchronization to add the logic you describe. On top of that, flock()
on NFS is local prior to Linux 2.6.12, so if any of your NFS client
machines aren't running .12+ but use flock(), you now have different
machines getting different locks on the same file from different servers.

> Perhaps someone could shed some light, tell me it's stupid, or tell me
> it's worthwhile? I know this is the memcache list, and not a
> filesystems list, but perhaps it might spur some discussion.

I'm still not sure I comprehend the problem you're trying to solve.
Relevant bibliography, however:

 http://www.citi.umich.edu/projects/cluster_nfsv4/
 http://www.citi.umich.edu/projects/gridnfs/index.html
 http://www.citi.umich.edu/projects/gridnfs/draft-welch-pnfs-ops-01.txt

Memcached is not a DLM, you probably really don't want to use it as one,
and so you might want to take the discussion to a (N)FS-oriented list
instead.

-- 
Ivan Krstic <krstic at fas.harvard.edu> | 0x147C722D