Coda File System

Re: the truth(?) about volume names role (was: Coda development roadmap)

From: <>
Date: Sun, 3 Aug 2014 11:55:54 +0200
On Sun, Aug 03, 2014 at 02:47:47AM -0500, Troy Benjegerdes wrote:
> > Such usage requires the presence of a corresponding reliable
> > "volume names to volume numerical ids mapping" service.
> > 
> > This service can be otherwise dropped, without losing any functionality.

> > I do not mind implementing better tools than a paper sheet, but it is
> > important to implement them separately.

> I think you just re-invented DNS

This might be true, as Jan also mentioned in
"Devils advocate here, ... put everything into DNS with volumename.<realm>
DNS records."

if it were not the uncontrollable leaking of volume id data and of the
access patterns (see
"Can we accept leaking the volume ids? ..." and the following text)

> Is there any reason not to use DNS? If having the coda server be able 
> to make updates is important, then make it a delegated subdomain and
> have the coda server run a process that answers on port 53 with human
> readable file-to-number mappings.

Indeed, if you are satisfied with exposing such information to the whole
world (and/or relying to site- and situation-specific means like firewalls).

> Why not make a DNS server that uses Ubik as the back-end database?

(As a side note, are you aware of e.g.
 "There are a number of scalability and performance issues with UBIK
 that must be addressed." on ?)

> Is there anything better *in practice* that is widely deployed, simple,
> and reliable?


But this fact does not make the "volume name to volume id" mapping useful
at file access time, nor make DNS applicable to do this task.

Separating the mapping to belong to exclusively management context does
not of course make DNS any "less" usable as the corresponding means either
(actually the separation can make it more usable - the requirements
become more relaxed).

Thanks for sharing your thoughts Troy!

Received on 2014-08-03 05:56:30