Bachman Kharazmi wrote: > On 10/23/05, Matthew Weigel <[EMAIL PROTECTED]> wrote: >> Well, except that hard links are filesystem specific, you can't cross >> filesystem boundaries with one. >> >> Also, depending on design, you probably actually want a single RO >> filesystem to serve as / for all diskless clients, and have smaller >> per-client RW volumes (like /etc) or per-user RW volumes (so each >> machine >> is identical and everyone can use each machine). > uhm, so it would be possible sharing all dirs except /etc?
That's not what I said, no. Having clarified that point, I don't think I need to respond to what you wrote below where you presumed to know my answer to that question. > Each machine is identical? In terms of FS layout, what software is available where, etc.- yes. It's one approach for some problems - depending on design, like I said. > yes maybe in that case that would work. But where I'm going to use my > doc is a uni env where all the clients are not identical. Even if they > were, what would you do if hw failed on one of clients? I'm having a bit of trouble imagining what hardware failures could be "handled" by a change to filesystem layout. Regardless, I'll note that I was responding to the proposition that *everything*, from / on down, could be shared from one NFS export. In the cases where *that* seems like a good idea, what I describe is better. If sharing that much doesn't, then what I describe may not, either. > So a script that sync one of the clients from server, and then all the > other clients can sync from that up2date client. Are we still talking about diskless clients? Why on earth would you synchronize them over the network, so that they have to perform NFS reads and writes to effect the changes? > Remeber that if the purpose is 'personal' thin clients you would > confuse ppl saving tons of files in everyones /home. I confess to being confused by what you're saying here. -- Matthew Weigel hacker [EMAIL PROTECTED]
