Re: reiser4 plugins

[Valdis . Kletnieks]

On Mon, 27 Jun 2005 00:54:17 CDT, David Masover said:

> There has been some mention of inheritance, but I've forgotten how
> that's supposed to work.  If there's some sort of inheritance where
> children inherit properties of their parent directory, and also inherit
> changes to those properties, than Hans probably wants that to be the
> prefered way of doing things?

Well, the 'chmod g+s dirname/' example *is* just "children inherit the
group of the directory", and somebody didn't like that.. ;)

> > Now throw in multiple users and CPU limits.  User A enters that directory and
> > references everything, causing the buffer cache to get filled up.  While there,
> > A makes changes, so the pages are dirty - "for i in */*; do echo " " >> $i; done"
> > would do the job...  User B now does something that causes a writeback of one
> > of those buffer cache pages.
> > 
> > A) What process currently gets ticked for the CPU and I/O for the writeback?
> > 
> > B) In your model, who will get ticked for the resources?
> > 
> > C) Will the users riot? (Note that you can't win here - currently, the "price"
> > of writing back A's and B's pages are about equal.  However, if A gets dinked
> > for an expensive writeback due to B's process, A will get miffed.  If B gets
> > charge for an expensive writeback of A's, B will get miffed. If you say "screw it"
> > and bill it to a kernel thread, the bean counters will get miffed... ;)
> 
> If I understand this correctly, this is somewhat like if user A creates
> a 50 meg file on a system with 100 megs free RAM, and user B runs
> "sync".  Also similar to if B were to suddenly fill up 75 megs of RAM,
> forcing A's file to be flushed -- last I checked, in Reiser4, only a
> sync or memory pressure causes writes to flush.

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.
However, if one user has a much higher per-page cost than the other, the
imbalance can start to matter *very* quickly....

> Right?  This is tempting to comment on, but I want to make sure I grok
> it first...

For more fun, consider how you can write 1 megabyte of data to a file,
lseek to the beginning and start writing again - and you go over quota
on the *second* write even though you're over-writing already existing
data.  Can happen if you're compressing, and the second write doesn't
compress as well as the first. (To be fair, we already have similar
issues with sparse files - but at least 'tar --sparse' has an easy way
to deal with it compared to this. ;)

Attachment: pgp00000.pgp
Description: PGP signature