> The B-trees I'm used to tree divide in arbitrary > places across the whole > key, so doing partial-key queries is painful.
While the b-trees in DEC's Record Management Services (RMS) allowed multi-segment keys, they treated the entire key as a byte-string as far as prefix searches went (i.e., the segmentation wasn't significant to that, and there's no obvious reason why it should have been in other implementations). > > I can't find "Structured File System" "Transarc" > usefully in Google. Do > you have a link handy? If not, never mind. Well, transarc.com now leads to a porn site, so that's not much help. And Wikipedia's entry for Transarc is regrettably sparse. Transarc was a Pittsburgh R&D company formed by some *very* bright CMU people. It's probably best known for its 'Encina' distributed transaction environment (SFS was actually part of Encina, but IIRC a separable one), for having developed the distributed file system (DFS) component of the Open Group's Distributed Computing Environment (DCE), and for AFS, the productized (and now open source) version of CMU's distributed Andrew file system; my own acquaintance with Transarc became closer when I was helping develop a distributed transactional object system in the mid''90s and we were using their book "Camelot and Avalon" for high-level design inspiration. They were always closely associated with IBM, which absorbed them as a wholly-owned subsidiary in 1994 (and I've heard relatively little about them since). SFS was one of their lesser-known achievements: a record-oriented transactional file system. I've always felt that system-managed record-oriented files were useful, in part because a lot of the nitty-gritty space management that's required (e.g., to handle the structured pages that tend to be necessary to accommodate data that's allowed to change its size or is required to remain in some key order under insertion/update/deletion activity) duplicates similar space-management required of the system to manage conventional byte-stream files and in part because any kind of system-wide lock- and deadlock-management facilities tend to want to tie into such data at a higher-than-byte-stream level (e.g., because the locked entities may have to move around) - so SFS was interesting to me. Unfortunately, it's been long enough that I can't remember too many details about it - e.g., it may or may not have supported interlocked access at the record field level - and at least after a qui ck search I can't find any papers about it that I may have downloaded (that era was before I really recognized how evanescent Web material often may be). I actually did get a Google hit at position 19 with the search terms you used (after a plethora of hits on "log structured file system", of course), but it wasn't very enlightening. Nor were several later ones, until hit 42 at the University of Waterloo - a .pdf that contains at least a brief description starting on page 21 (including a thinly-disguised rip-off of a figure in Gray&Reuter's classic "Transaction Processing" - but it's not quite *identical*...). Aha - good old reliable IBM *does* still have some SFS documentation on line that hit 75 noticed; munging that URL a bit led to http://publib.boulder.ibm.com/infocenter/txformp/v5r1/index.jsp?noscript=1 (expand "Encina Books" in the left-hand frame and start digging...). - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
