| gabriel rosenkoetter on Mon, 10 Jun 2002 22:20:26 +0200 |
|
On Mon, Jun 10, 2002 at 02:20:19PM -0400, Chris Beggy wrote: > > [Deleting the In-Reply-To: line on purpose so that this breaks into > > a separate thread in threaded mail readers.] > Oops, my bad. Fwiw, I don't mean those terse [] comments to sound angry, just be a short explanation so that nobody gets confused. :^> > Most days, I don't worry about it. Your post brought back bad memories. Things are much better than they once were already, and will hopefully be getting better. > Sounds like a token passing scheme... Um, yeah, pretty much. But my description doesn't go into all the detail. I *think* they had some heuristics to be a little bit more smart about where a file's backing store lived, and there was also talk of treating the network drives the same way Berkeley LFS treats a local hard drive (write everything to a log, make space later with a cleaner agent that shuffles good data out of mostly-stale tracks into good tracks, then adds the blocks in the cleansed stale tracks back onto the block free list). But it's all a little hazy. Sean might be able to tell you more if he's been looking at it recently. > How about networked attached storage schemes (NAS)? Do they all > rely on sun nfs as well? I haven't worked with any (well, we've got a Snap! server sitting in the server room that doesn't seem to be doing much, so I could go take a look at it, but I'm waiting for a rather important phone call at the moment, so...). I would expect that they are someone's proprietary implementation, where they aren't actually just an embedded Linux (or other; NetBSD is actually rather popular for this, as it turns out) machine doing whatever NFS is there. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpSNnk2eJ3Ip.pgp
|
|