On Mon, 1 May 2000, Roman V. Shaposhnick wrote:
> On Mon, May 01, 2000 at 01:50:58PM -0400, Alexander Viro wrote:
> >
> >
> > On Mon, 1 May 2000, Roman V. Shaposhnick wrote:
> >
> > > 2. at the same time can work with stackable or derived ( in C++
> > > terminology ) host objects like file->dentry->inode->phis.
> >
> > These are _not_ derived in C++ sense. Sorry.
>
> Ooops! I mean, aggregation, of course, but nevertheless I just try to
> express the idea using less possible number of words.
> Ok, what about the idea ?
Tokens. Opaque tokens. Interface should not care about them. Callers must
know what they are dealing with, indeed.
> > > > Inode data pages are per-inode, not per-dentry or per-file-struct.
> > >
> > > Frankly, inode data pages are file pages, because it is userspace files we
> > > care of. Nothing more, nothing less.
> >
> > You've missed the point here. We cache the data on the client
> > side. _All_ openers share that cache.
>
> You mean local, client side openers ?
Yep.
> > IOW, we have a chance that data submitted by one of them will be sent with
> > credentials of another. Nothing to do here.
>
> For now? Yes. But if we would be able to use "struct file *" than we could
> store all meta information on a per opener basis. That's the idea. And we
> could always separate one opener from another by syncing each and every
> operation. Yes?
All meta information? Consider mmap(). You have a dirty page. It might be
dirtied by a process that has it mapped. It might be dirtied by direct
write() by another opener. You end up with the need to generate Rwrite.
And no way to separate the data from different openers. So either you use
a new cache for each opener (_big_ waste of memory + hell of coherency
problems) or you end up with the described effect.
