Your first paragraph suggests you look down on the idea - do you?
It was grossly ahead of its time (remember, this was the late 90s). The assumption was that the network was faster than the disk, which in our implementation was never true because it required a reliable backing store, so it was network latency + disk desktop disk latency. And we couldn't use a lot of RAM as cache because desktops didn't have multi-gigabyte memory at the time -- even servers didn't.
How far did you get and what happened to it?
I assume it's on some backup tapes somewhere. Every so often I come across an old CDROM I made during the era and get this idea that the source code is buried on it somewhere. It was tied pretty closely to early 2.0 Linux kernels and the block layer that existed at the time (I don't know how much would be portable to modern kernels).
A certain company that sued Microsoft for a patent related to embedding executable content in web pages, that we had a working relationship with at the time, had claims on their web page that they owned the trademark for it, but as far as I know, we were the only ones to produce working code.
Both of us who were working on it eventually left for greener pastures (and that was like 12 years ago at this point).
I wasn't suggesting a VM based idea, more of a daemon/windows service.
Nah, davecampbell in this thread suggested the use of VMs. Using a VM might make deployment easier. There wasn't anything like vmware player back when I worked on this, and we had to go around to everyone's machine and install the new versions after hours with every release.
there's no real need for it to be a filesystem per-se, it could be any kind of store with a central interface (web based, for instance) and then it wouldn't have to deal with parts of a filesystem vanishing arbitrarily.
True. And with removing that constraint/use-case, there are a number of things today that already provide this: Amazon S3 is one. We implemented it as a generic block device and put a filesystem on top of that, mainly for testing. One of the "goals" was to eventually use the block device as an Oracle tablespace file (once ported to HP-UX, since Oracle didn't exist on Linux at the time, or had barely come out for Linux).
Like I said, if you want to do this today, try it with something like md on top of NBD. Although, see the section "Late news - intelligent mirroring" on http://enbd.sourceforge.net/ (which is itself old).
But today, I wouldn't even bother. I'd just bite the bullet and buy the disks (or use some other system that is more directly under sysadmin control than employee's desktops). I think there's way too much variability in using desktop clients that were deployed for another use (desktop use) for this purpose.
It was grossly ahead of its time (remember, this was the late 90s). The assumption was that the network was faster than the disk, which in our implementation was never true because it required a reliable backing store, so it was network latency + disk desktop disk latency. And we couldn't use a lot of RAM as cache because desktops didn't have multi-gigabyte memory at the time -- even servers didn't.
How far did you get and what happened to it?
I assume it's on some backup tapes somewhere. Every so often I come across an old CDROM I made during the era and get this idea that the source code is buried on it somewhere. It was tied pretty closely to early 2.0 Linux kernels and the block layer that existed at the time (I don't know how much would be portable to modern kernels).
A certain company that sued Microsoft for a patent related to embedding executable content in web pages, that we had a working relationship with at the time, had claims on their web page that they owned the trademark for it, but as far as I know, we were the only ones to produce working code.
Both of us who were working on it eventually left for greener pastures (and that was like 12 years ago at this point).
I wasn't suggesting a VM based idea, more of a daemon/windows service.
Nah, davecampbell in this thread suggested the use of VMs. Using a VM might make deployment easier. There wasn't anything like vmware player back when I worked on this, and we had to go around to everyone's machine and install the new versions after hours with every release.
there's no real need for it to be a filesystem per-se, it could be any kind of store with a central interface (web based, for instance) and then it wouldn't have to deal with parts of a filesystem vanishing arbitrarily.
True. And with removing that constraint/use-case, there are a number of things today that already provide this: Amazon S3 is one. We implemented it as a generic block device and put a filesystem on top of that, mainly for testing. One of the "goals" was to eventually use the block device as an Oracle tablespace file (once ported to HP-UX, since Oracle didn't exist on Linux at the time, or had barely come out for Linux).
Like I said, if you want to do this today, try it with something like md on top of NBD. Although, see the section "Late news - intelligent mirroring" on http://enbd.sourceforge.net/ (which is itself old).
But today, I wouldn't even bother. I'd just bite the bullet and buy the disks (or use some other system that is more directly under sysadmin control than employee's desktops). I think there's way too much variability in using desktop clients that were deployed for another use (desktop use) for this purpose.
A friend of mine pointed me to this http://portal.acm.org/citation.cfm?id=844130&dl=ACM&...