On Oct 26, 2011, at 16:55 , Andrew Deason wrote: > On Wed, 26 Oct 2011 07:34:04 -0700 (PDT) > Booker Bense <[email protected]> wrote: > >> Ideally, you'd like one mini-server per user volume and at least the >> user would only shoot himself in the foot. I don't think this is >> particularly practical even with current VM's, but how far can you >> push it? > > You don't necessarily need VMs for this; at least, I'm not sure I see > what benefit you get from separating these via VMs. You can (with I > think 1.6.0 or a patch to 1.4.x) run these as chrooted fileservers on > the same box, which would have less overhead. > > I think you could push it pretty far as far as resource utilization on > the box goes, since the fileserver can scale down pretty small wrt > memory usage. However, keep in mind that in the current implementation > you need one IP per fileserver, which is the resource you may run out of > first unless you have a lot of unused ipv4 space.
Good point. This problem will vanish with IPv6, though. Containers could be another solution. Running multiple fileservers on different ports on the same system would be even more efficient. Is this possible or could be implemented (in theory)? > This also doesn't help you much if the server is getting bogged down due > to the I/O in servicing the relevant requests, unless you separate the > user volumes physically. A single 1.4 fileserver is not able to make a decent contemporary fileserver sweat. I don't have much data on 1.6 servers. > But for the simple (and presumably common) case > of running out of fileserver threads or the fileserver not being > mp-scalable, sure. We're suffering from the same problem as SLAC, and are working around it by keeping home directories small enough to make them unusable for use from the compute farm and providing extra volumes on fileservers dedicated to workgroups. User education tends to be more effective if careless use penalizes familiar co-workers only ;-) What would be a great feature to have is a way to keep the server from using more than, say, half of the available threads for a single volume. Would this be feasible to implement at all? -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
