On Mon, 27 Jun 2005 02:07:46 CDT, David Masover said: > > Exactly the same sort of thing - traditionally it's been more or less > > ignored > > in the system accounting, because A would usually average out to causing as > > many I/Os as B did, and they were roughly equal in cost so it was a wash. > > Even if A is doing A/V work and B is programming?
I said "traditionally" - it's been a "oh well, we can't do much about it" problem for a *long* time (for instance, time spent in an interrupt handler has usually been charged off against whoever's timeslide the interrupt handler took a chunk out of). It's only been tolerated so far because (a) the costs for both users are about equal and (b) you rarely have a heavy I/O DB and a number cruncher on the same box, or a user doing A/V work and a user doing programming - if it's not a single-use machine, there's *multiple* number crunchers, DBs, or programmers, and they tend to balance out. Said tendency can dissapear quite easily here.... > How do we get over quota errors, btw? Can we get them from write() > calls? If so, I don't see a Problem(TM), just an annoyance. One gotcha here is that it means that you can't do delayed allocation on writes - you *have* to allocate disk space at each write and then update the quotas. (And yes, I know that 'man 2 close' says that bad stuff can happen to your data even after your program exits - that doesn't mean we should go out of our way to make things worse.. ;)
pgpUHb5i8cnuK.pgp
Description: PGP signature