That was one of the beauties of the Sun implementation. The workstation kernel (or micro kernel?) did check to see for every file when accessed if it was considered 'most resent'.
If it wasn't and say you were booting and the kernel was upgraded, the one in the cache was marked invalid and a new one was downloaded. It has to be built in at close to the file system level for it to have a ghost of a chance to work reliably. Yes, when we first deployed it, our 100BaseT network was hammered. But it settled down pretty well. Still lots of 'chit chat' validating files that were already cached. Given the headache we had keeping a couple of hundred Sun workstations going with 3 people (lots of high maintenance users ... geophysicists doing work on seismic surveys mainly, some geologists and other geo-geeks) it kept us running. Really 'high end' users we still left everything local, but many were compute and not data bound so these cached systems worked pretty well. Back then 8G was a 'big disk', and yes, we did raid5 groups with hardware raid controller, and striped those together when we needed 'bigger' disks. ... Spent a lot of time on disk maintenance in those days. Users backed up their own data to 8mm tape too. ><> ... Jack Whatever you do, work at it with all your heart... Colossians 3:23 "You don't manage people; you manage things. You lead people." — Admiral Grace Hopper, USN "It’s easier to ask forgiveness than it is to get permission" — Admiral Grace Hopper, USN "If you are not part of the solution, you are part of the precipitate" - Henry J. Tillman fax: 630-214-5954 g-voice: 615-746-7104 to leave a message <http://appsumo.com/%7Euvlm> On Tue, Oct 18, 2011 at 4:13 PM, Steven S. Critchfield <[email protected]>wrote: > Net booting is nothing special if your netcard supports it. > > Trouble with a local cache would be how would you know when the central > image changed? Essentially, if you cached a local copy and are not the only > one accessing the filesystem, you do not know when the remote file changed. > > Normal cache and swap would handle most of the problems you would have. > Most used apps would be cached the same as if it had been a local > filesystem. Given time and memory starvation, it will cycle out until needed > again. > > I'm sure if you wanted to, your bin dirs could be mounted through a simple > fuse fs that would copy them locally when being used. > > ----- Original Message ----- > > Once upon a time SUN had a way to 'net boot' machines, typically > > desktops. Then it used the local > > disk for swap and cache of data and programs only. It used LMRU > > algorithm's to figure out what to > > dump out of cache when it got full. I was impressed if you put in a > > non-formatted disk it would partition > > and format it on the fly as needed. > > > > The good thing was that when files were updated/changed/written > > locally, they would be written back > > to the server (home directory mostly). If a local disk died, just > > replace it, reboot the machine then > > it would run slowly (building the cache, just like when the machine is > > 'new') but it would run and > > did apparently speed up as more was put into cache. > > > > My question is, is there such a thing available on Linux? > > > > I have heard of kiosk machines that did everything over the 'net, but > > this with local cache had some > > of the best of both worlds. > > > > ><> ... Jack > > http://appsumo.com/~uvlm <-- Enter to win 50G Dropbox for life > > > > -- You received this message because you are subscribed to the Google > > Groups "NLUG" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] For more options, visit this > > group at http://groups.google.com/group/nlug-talk?hl=en > > -- > Steven Critchfield [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en > -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
