Archive for the ‘Cascade’ Category
Cascade 18.104.22.1689 has been released! This release adds a bunch of new features, such as exclusive locking, “Details” columns in the shell extension, and named checkpoints, as well as performance enhancements and bug fixes. For a detailed list, check out the release notes. Try it now…
Cascade 22.214.171.1241 has been released! This is primarily a bug fix release with a few minor new features. The exact changes are spelled out in the release notes. Try it now…
Cascade 126.96.36.1993 has been released! This release adds a number of new features. The full list of what’s changed is spelled out in the release notes. Try it now…
What’s more, Cascade is now completely free for personal use, even in a corporate environment. Multi-user installations still require you to purchase a license. The details are spelled out on the Pricing page and in the EULA at install time, but the bottom line is that you can use Cascade for as long as you want on as many computers as you want, so long as it’s just you using Cascade and accessing your Cascade servers.
Cascade 188.8.131.520 has been released! This release fixes a variety of bugs, some minor and some major, in Cascade 1.0.1. It also provides several important performance enhancements, especially to checkpoint and commit operations. A list of specific noteworthy fixes is provided in the release notes. Try it now!
Cascade 184.108.40.2064 has been released! This is a bug fix release that addresses a variety of issues, mostly minor, with Cascade 1.0.0. A list of specific noteworthy fixes is provided in the release notes. Try it now!
After the recent release of Cascade 1.0.0, our old Flash demo of an earlier version of Cascade was starting to look a little stale and has been cleaned up and replaced with a newer demo based on the latest release. In addition to using a newer version of Cascade and featuring newer, prettier-looking Cascade Manager web pages, the demo is quite a bit shorter now: 15 minutes rather than 25. The audio quality has also been cleaned up.
Cascade 220.127.116.119 has been released! This release includes a number of major enhancements:
- The addition of a user manual. In addition to being linked from our web site, you can access the manual via the Start Menu, via any right-click context menu, or via a button on the nav bar on any Cascade Manager page.
- Greatly simplified installation of Cascade on Linux and Macintosh. Most tasks are now performed by an installer script.
- Further usability enhancements to Cascade Manager, including color-coding in tables (e.g. failed tasks are highlighted in red) and a new Revisions page with improved status reporting that replaces the old Home and Grid pages.
- Checkpoints are now simply revisions with a dot, instead of a long unique ID: for example, revision 10.1 is the first checkpoint created so far relative to revision 10.
- Other minor bug fixes and enhancements.
Currently, as of version 0.2.1, Cascade supports Perforce, Subversion, and Alienbrain repositories. If you’re using some other software to manage your repository, unfortunately, we don’t have a way for you to use Cascade just yet. However, we’ve been careful to design Cascade so that we can easily add support for more repository types in the future, so you’re not completely out of luck (please don’t hesitate to contact us if you’re interested).
Let’s step back and look at the architecture of Cascade File System and Cascade Proxy a little bit. Both are services that run in the background on a PC. Both receive requests for data from some external source — CFS gets them from the file system layer in the kernel, Cascade Proxy gets them from a network connection. Both use caching to satisfy those requests more efficiently: once a file is downloaded for the first time, it’s stored in the cache, so we don’t have to download it again on a second request for the same file. In fact, CFS and Cascade Proxy both share the same “cache manager” implementation, although they make use of it in a somewhat different way.
The Cascade cache manager thinks of files in terms of their URL — for instance, svn-http://svn.collab.net/repos/svn. This URL encodes all of the information necessary to find the file: what type of repository it lives in, the hostname of the server to connect to, and the path of that file on the server.
When a cache miss happens, the cache manager needs to download the file. If it is configured with a proxy server, it will forward the request on to the proxy, without regard to what type of repository we are dealing with; the proxy server will take care of everything for us. If we don’t have a proxy server, it will obtain the file directly from the repository. To do this, it looks at that first part of the URL and passes the request to one of several “repository query” backends:
- Requests for URLs beginning with “p4:” will be forwarded to the query_p4 library.
- Requests for URLs beginning with “svn-http:” or “svn-https:” will be forwarded to the query_svn library.
- Requests for URLs beginning with “ab:” will be forwarded to the query_ab library.
Each of these query libraries implements a common API. To add a new repository type, all we need to do is implement that API — map the standard set of queries the Cascade cache manager uses to the queries that we can make to the repository. Then, we simply assign it a unique URL schema as above and add it to a table, and we’re done! It’s pretty straightforward.
What about third-party addons to support new repository types? We’ve considered the possibility and may offer some way to do this in the future, but for now we believe providing a third-party API for this would probably cause more problems than it would solve.
Cascade 0.2.1.647 has been released! This release, aside from fixing various minor bugs, includes a redesign of the Cascade Manager web pages. The screenshots on our web pages have been updated accordingly. (The Flash demo hasn’t been updated yet.)
A common worry with Cascade File System is that building through a file system layer like CFS will be much slower than building off a regular local disk using a file system like NTFS. After all, building off a network file system like SMB/CIFS or NFS is typically much slower than building off a local disk.
Rather than just speculating, let’s take a look at some real numbers. I measured wall-clock time for the same build in three scenarios: building off a local NTFS drive, building off CFS, and building over SMB off a Samba server on the same LAN with a ping of about 300 microseconds. (These are actually times from the second of two clean builds in a row; the first build primes the caches in the system, eliminating sources of variability in the second run.)
As these numbers make clear, using a network file system as an analogy for CFS performance isn’t quite right. If the files and metadata you need are already in your CFS cache, CFS will not generate any network traffic. Further, CFS cache entries don’t “time out” or “expire”, and the main part of your CFS cache (the file data) will persist even after an OS reboot.
Does CFS have overhead? Sure, of course it does. There’s plenty of performance tuning that can still be done on CFS. At the same time, CFS also has at least one big performance advantage over modern disk-based file systems like NTFS and ext3fs: it’s not journaled. A CFS tree is just a workspace; the real data that needs absolute protection is the data in your repository and in your Cascade Manager checkpoints. If your OS crashes or your computer loses power, no big deal — you can just clone from your last checkpoint (checkpoints are cheap, so you can create them as often as you’d like). Journaled file systems, on the other hand, go to great lengths to ensure that once certain types of data have been written to disk, they cannot be lost even in an OS crash or power loss. Flushing data out to a hard drive is expensive: you have to wait for the hard drive to spin and seek to that spot on the drive, which can take milliseconds. CFS can skip all of this extra work.
Now, if we compare to a network file system — the details differ from file system to file system, but many network file systems don’t make much of an effort to cache, since someone else might change the files on the server at any time. Some will do limited amounts of caching but will “time out” cache entries, say, after 30 seconds, and ask the server again for the information. (Of course, this leaves a window of 30 seconds where you could get the wrong answer to a query!) Some will send a request to the server each time you open a file, asking whether the file has been changed since they last cached it, but this still requires a network round trip. Some support “oplock” functionality where they request that the server notify them when their cached data fall out of date, but not all servers support this, those that do might limit the number of outstanding oplocks, and the server can arbitrarily refuse or break oplocks at any time. The cache data is in memory and is lost either on reboot or even when the OS’s VM system needs to free up some pages to make room for other data.
There are also typically many other inefficiencies in network file system stacks — for example, packing and unpacking requests and replies, the TCP/IP stack, breaking up large requests into smaller ones to satisfy limits in the protocol, limited numbers of requests in flight (a serious problem if combined with network latency), overly “chatty” protocols that require many round trips to do simple operations, and sometimes just poorly-optimized client or server software.
Bottom line: once the files you need are in your CFS cache, CFS’s performance is similar to that of a local disk-based file system such as NTFS. CFS is much faster than a network file system like SMB.