On Mon, Nov 11, 2002 at 10:19:31AM +0100, Fabrizio Morbini wrote:
> Hi, Can Coda handle file with size bigger than 2 Giga?

I'm pretty sure it doesn't. And would even go as far as to question
whether it is all that useful.

Coda uses whole file caching, so you have to wait for the whole file to
be fetched, as well as the whole file being written back when it is
changed. On a 100Base-T network that will easily take over 4 minutes if
everything goes right. Also, the metadata vs. data ratio's in the client
will need to be changed. Right now venus assumes a 'normal' distribution
with an average filesize of about 16KB per file. So if you set venus up
for a multi GB local cache, it will assume you are going to store
millions of files.

Such large files are in most cases either CD-images or databases, and it
is mentioned many times all over the website, Coda Howto, system admin
manual, mailinglists that trying to store databases in Coda is not
supported.

Coda does not provide locking, so any concurrent updates can and will
lead to conflicts. Because of the session semantics, updates are not
propagated to other clients until the database file is closed, which
typical database programs never do because for them it is a waste of
performance closing and reopening a file. When a database is only used
for reading, the database library/software typically still opens it
read/write, because it can avoid reopening in case you decide to modify
data after all, as a result Venus automatically assumes that the file
has been updated and will write back the file even if nothing was
changed. And many more reasons why it is just a bad idea.

Databases have their own methods for access across a network and
replication. Those methods are tried and tested, if a database doesn't
provide ways to replicate it's data, it is probably because it isn't
that easy.

For CD-images, it is possible to store the actual contents of the image.
That way clients can access the data without needing a loopback mount
and an isofs image can easily be recreated.

Jan