Phil Nelson wrote:
> There is a new Windows Coda Client now available, the Beta-3
> version.  You may find this this new windows client at
>
>   ftp://coda.cs.cmu.edu:/pub/coda/winnt/ntcoda-b3.exe
>
> This release is a quick kernel bug fix for the beta-2 distribution.
> There are no changes to the other parts of coda.  Userland is
> version 6.0.16.
>
> I would appreciate people trying this release and sending me a report.
> I have found that the VLC media player (http://www.videolan.org/vlc)
> works well with the "big file" support provided by the beta-3 release.
>
> The following is the Windows part of the 6.0.16 release announcement.
> In case you didn't read that far in the 6.0.16 announcement, here
> it is again. (Slightly modified for the beta-3 release.)
>
> --------------
>
> This Windows client release includes:
>     1) bug fixes:  symbolic links should work (but repairs do not work.)
>     2) new feature:  "big file" support (see below)
>     3) newest release of OSR's fsdk that includes some bug fixes.
>
> The major change is for "big file" support.  First, the only
> implementation of "big file support" is in the Windows beta-2 release.
> This doesn't mean that it won't migrate to the Linux/BSD releases
> some day.  The Windows implementation was kind of a quick check out the
> concept implementation.  As such, we would like feedback on how it works
> for you.
>
> Next, what is "big file support"?  Well, it is assumed that most
> venus caches have a relatively small cache, say in the range 500Mb or
> smaller.  (The default value for the Windows beta-2 is 100Mb.)
> So, how would one be able to put their favorite large media file
> in Coda and use it?  Many media files (DVDs) are much larger than a
> standard venus cache.  This brings up two problems in most cases:
>     1)  the file won't fit in cache
>     2)  even if it fit, it takes a long time to move the file to cache.
>
> How does big file support solve both of these?   There is a tool,
> mkcodabf, that takes a large file from some place (your media file)
> and produces a tree of small files, each hunk is currently a multiple
> of 1Mb in size.  The tree could be up to two directories deep.  The
> last thing written in the top level directory is a file named
> _Coda_BigFile_ that contains the meta data for the directory tree:
>     total number of bytes, number of directory levels, hunk size
>     maximum hunks (files) per directory, ...
>
> When the Windows kernel module sees the magic file (_Coda_BigFile_),
> it returns information that makes the top level directory look like
> a big regular file.  The rest of the system and userland just see
> one big file.  It is marked read only so that we preserve write
> semantics.
>
> Now, a media player can now read and play this big file.  And to
> support the media stream, the semantics of the vget upcall to
> venus changed just a bit so it now fetches the data into the
> cache, but returns immediately after scheduling the fetch.  So,
> when the file is opened, the first hunk is fetched and the
> process is blocked until the first hunk is in the cache.  After
> the first one arrives, the kernel module vgets the next sequential
> hunk.  At this point, the process can read from the first hunk.
> Once it moves into the next hunk, the following hunk is fetched
> via vget.   So, while the media player is playing one hunk, the
> next sequential hunk is being fetched by venus so that when the
> media player needs the next hunk, it is in the cache ready to be
> read and there is no interruption in the data flow.  Random access
> is still supported, except the read to a random location may have
> to wait for the hunk to be fetched.
>
> Venus doesn't see the directory tree as a single file, just the
> users of the Coda file system.
>
> Coda-6.0.16 includes the mkcodabf program as well as a manual page
> explaining its use.
>
> --------------  Additional information --------------
>
> When one "deletes" a big file, it only deletes the big file attribute.
> To do that, the coda kernel module deletes the _Coda_BigFile_ file in
> the "big file's directory" and then the full file tree becomes visible
> to the client.
>
>
>   
so will big files be created automatically if a user creates a file
that's bigger than the cache?