On Wed, Oct 16, 2002 at 12:09:24AM -0400, Kevin Atkinson wrote:
> With the new system the open call can return immanently.  Then in the 

And how are reads and writes going to tell whether the part they are
accessing is available? By having to bounce every single call up to
venus for validation, or we would need to store possibly large bitmaps
in the kernel to flag blocks as accessible or not.

> I see the fact that coda has to download the entire file at once before
> any reads can take place as a rather serious limitation.  There are many
> times when only the first part of of a file is read in and the user has no
> intention of reading the rest of the file.  For example when scanning a
> directory of JPEGS with previews or Music files for the tag information.  
> Etc...  The larger the files are the more of an issue this becomes.

Actually mp3v1 tags are typically at the end of a file, so you'd have to
wait for the whole file anyways. With mp3v2 it is even worse, because
tags are allowed to be interspersed anywhere within the file, you
actually need to read everything to extract all possible tags.

It is an application problem, not a filesystem problem. Other
filesystems do have the same semantics as Coda, for instance a
hierarchical storage system where files are pulled of a tape by a robot
if they are not available on disk.

The image viewer I often use does it right, it has the previews in a
subdirectory '.xvpics', as separate files and as such has no problem.
Same thing with my mp3 car radio (riocar/empeg player) It stores a
database of all the tags in a separate file, so that it doesn't have to
scan through every file on the disk to show a playlist, or do searches.

> And when dealing with huge files 1+ Gig files it really matters.  I really
> don't want to download the entire file just to preview the first couple of
> seconds.

If you're only working with blocks of a couple of seconds, split the
huge 1Gig files in blocks of a couple of seconds, problem solved.

Jan