Coda File System

Re: Coda-7.0.1 release

From: <u-x417_at_aetey.se>
Date: Sat, 22 Dec 2018 15:46:26 +0100
On Fri, Dec 21, 2018 at 11:47:27AM -0500, Jan Harkes wrote:
> On Fri, Dec 21, 2018 at 11:21:59AM -0500, Jan Harkes wrote:
> > Just a heads up, I just pushed out Coda-7.0.1 and it has several
> > features that are in development, one of which breaks RVM compatibility
> > on the Coda client.
> 
> I guess I should expand a little on the new features.

An impressive work, congratulations.

> - codatunnel enabled by default
> 
>     Coda clients and servers now spawn a helper daemon that tunnels RPC2
>     and SFTP through a TCP connection when possible. Because TCP
>     connections provide reliable ordered delivery we can suppress
>     certain retransmissions. Also masquerading firewalls are better at
>     tracking state of TCP connections unlike UDP where the redirections
>     are dropped after a short timeout, or in some cases when the first
>     'reply' packet is observed.

I understand the advantages of backward compatibility, but are
there any other compelling reasons to continue using UDP?

Are you considering to eventually make rpc2 talk TCP directly or in
some other way move to TCP-only communication without keeping an extra
protocol layer?

> - VASTRO, support for streaming large objects
> 
>     With this we allow a client to open a file before it is locally
>     cached and then we block on the read or mmap operations until the
>     accessed section has been fetched. Still a bit experimental and
>     needs kernel changes that haven't been upstreamed yet. Also the
>     cause for the RVM incompatibilities and slower reinitialization
>     times.

This looks like a nice usability feature, e.g. video files are an apparent
target (except those having their internal indexes at the end).

I assume that it is the dedicated Coda client module which needs
changes. Wonder how big they are? Which kernels are you targetting
(Linux, NetBSD, FreeBSD, Windows?)

Do you have an estimation of the performance impact compared
to the current situation of non-intercepted read()?

I would expect the complexity to be limited and the performance impact
small or negligible, as long as the changes only add conditional blocking,
not passing the file data. Is this the case?

Regards,
Rune
Received on 2018-12-22 09:47:13