Joerg Moellenkamp’s post explaining CacheFS has me excited:

Long ago, admins didn’t want to manage dozens of operating system installations. Instead of this they wanted to store all this data on a central fileserver (you know, the network is the computer). Thus netbooting Solaris and SunOS was invented. But there was a problem: All the users started to work at 9 o’clock. They switched on their workstations and the load on the fileserver and the network got higher and higher. Thus the idea of CacheFS [as a way of using the speed of local disk and the convenience of central management] was born.

Remove the corporate office and the uncaring sysadmins, and CacheFS might be exactly what I’m looking for to elastically expand the capacity of my laptop’s internal storage. This isn’t some newfangled technology, Sun developed it in the early 90s and it’s been available for Linux since 2003 (try it in Gentoo). And most importantly, it’s “designed to be as transparent as possible to a user of the system. Applications should just be able to use NFS files as normal, without any knowledge of there being a cache.”

The local cache isn’t expected to be a complete mirror of the remote filesystem, just the recently opened files. So the capacity of your local disk is limited only by your willingness to wait for files to be retrieved from the network. The biggest problem is figuring out what happens when the network isn’t available. CacheFS doesn’t appear to solve that and would likely fail if the network dropped.

I know nothing about filesystem development, but this challenge is interesting enough to make me consider jumping in. The availability of a partial solution helps too.

Ups to hindesite for the sweet drive photo. Too bad about what happened to it, though.

My Sun T2000 is here, and with Cliff’s help it’s now patched, configured, and online. (Aside: what’s a Sun Happy Meal?)

I’ll second Jon’s assessment that Sun really should put some reasonable cable adapters in the box, as the the bundle of adapters necessary to make a null modem connection to the box is ridiculously out of scale (I’ll get a picture soon).

I’m getting the application environment put together, which has turned out easier than expected thanks to the convenient packages from Blastwave.org. The box came with Solaris 10 installed, and after a quick installation and configuration of pkg-get I was happily installing Apache, MySQL, and PHP as simply as typing pkg-get -i apache.

AMP, AMPS, Apache, Blastwave.org, LAMP, MySQL, PHP, Solaris, Solaris 10, Sun, Sun Microsystems, T2000

A Solaris sysadmin I’m not. But now that I’ve finally got the Sun T2000 server I begged for a while back, I’ve got to ramp it up right quick.

The first task is to get a, um, LAMP environment up and running (SAMP?…oh, Sun wants us to call it AMPS). A bit of Googling turned up this forum thread that suggested Blastwave.org’s ports of PHP, MySQL, and Apache.

edit: I corrected the model number.

amp, amps, apache, lamp, mysql, open source, oss, php, solaris, sun, t2000

Jonathan Schwartz made the kind of news that makes Slash Dotters happy: he announced Sun is (sort of) giving away free servers. It’s a promotion, a media play, of course, but one that might make a few lucky people very happy.

Here’s the deal: Sun is really proud of their new T2000 eight core server. Each core runs at 1.2GHz, but they’re apparently applying some distributive power of multiplication and calling it an 9.6GHz machine and touting some impressive performance benchmarks. But rather than play the game of “our experts are better than your experts” against other vendors, they’ve extended a pretty generous try and buy program to users themselves. And, as Jonathan made noise in his blog post, a few people might get lucky enough to keep their machines.

So what’s my angle? WPopac rocks, and performance is excellent with my test corpus (160,000 bib records) on even a lowly single-CPU server with only 1GB of RAM, despite the fact that each bib record is represented in both its composed form in the wp_posts table and as about 20 more rows per record in a separate table (yup, I’ve got almost 3 million rows representing every atomic detail of every bib record), and all of this is full-text indexed.

And I’m fully confident that when I put our entire catalog into WPopac, all 330,000 bib records (resulting in about 6.2 million atomic records), performance will still be up to the task. My math suggests everything should be ducky on a relatively budget server up beyond about 1 million bib records, but what happens for libraries that have more than that, say, perhaps 6 to 8 million bib records (again, 110 to 150 million atomic records; again, all full-text indexed in MySQL)?

It would seem that WPopac’s combination of, um, large MySQL databases with high-volume Apache/PHP should be an ideal fit for the T2000’s big RAM space and support for high numbers of parallel threads. Jonathan claims the T2000 costs a modest $5,000 (but the online store shows a higher price?) and outperforms everything else, but is it up to WPopac? Do they want to try?

C’mon Sun, toss a T2000 this way, let’s see what happens? (Heck, I’ll even try a T1000.)

sun, solaris, t2000, coolthreads, server, 9.6ghz, challenge, sparc, ultrasparc, 8core, free, wpopac, performance, big db, Jonathan Schwartz , try-n-buy, try and buy, free server