> That has always been my plan. I just went for getting tmpfs working as
> fully as possible with semantics as close as possible to right and testing
> it, before considering touching the default pager code.
My current hacking is with the default pager and understanding Mach
internals. What are
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Faults are, well, ok. We'll never be able to give them on a
> > default-pager based interface, of course.
>
> What I'd had in mind was new default_pager_object calls to fix the size of
> a memory object (and clear pages past the new end). Those ch
> I don't have the previous messages, but I did grasp this much from the
> code. It might be that this is ultimately just a short-term hack for
> a tmpfs, however, and we have to hobble together what kludges work
> with it. I have some ideas about what the Right Thing would be; they
> all requir
Roland McGrath <[EMAIL PROTECTED]> writes:
> Despite what Thomas has said, I believe that it is reasonable for
> diskfs_truncate to return with allocsize arbitrarily higher than what was
> asked for. (It's up to the filesystem how it does allocation, and if its
> method overallocates a truncated
> Well, we have to do something, otherwise, when diskfs_drop_node is
> called, will trigger an assert.
>
> Consider the following: when diskfs_drop_node is called, if there is
> space allocated, it adds a reference and attempts to truncate the file
> to zero and happens to sets np->allocsize to
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > Diskfs_drop_node is called only when there are no outstanding
> > references to the file: including memory objects. If there is a
> > memory object reference of any kind, and diskfs_drop_node is being
> > called, you have a serious bug.
>
> This
> Diskfs_drop_node is called only when there are no outstanding
> references to the file: including memory objects. If there is a
> memory object reference of any kind, and diskfs_drop_node is being
> called, you have a serious bug.
This is wrong. Consider mmap; By SUSv2, we are allowed to:
Neal H Walfield <[EMAIL PROTECTED]> writes:
> Consider the following: when diskfs_drop_node is called, if there is
> space allocated, it adds a reference and attempts to truncate the file
> to zero and happens to sets np->allocsize to 0. diskfs_drop_node then
> drops its reference causing it to
> > (diskfs_truncate): We can truncate objects when they are being
> > truncated to a size of zero.
>
> Nope. That was my first thought too--when I wrote that code in the first
> place, it looked exactly like yours--but on further consideration I
> realized it won't do.
Well, we have
> > * tmpfs.c (main): Do not deallocate the underlying node;
> > servers deallocate nodes based only on the number of outstanding
> > protids.
>
> What is this supposed to be about?
In memory nodes are deallocated when there are no references to them (as
managed by diskfs_nref et al.
Roland McGrath <[EMAIL PROTECTED]> writes:
> file being truncated to zero and then enlarged. In fact, I believe (I'm
> not bothering to check POSIX even though the book is lying in front of me)
> the user is guaranteed that he can do:
If you ever bother to look it up, please let me know what yo
Thanks very much for working on this.
> * tmpfs.c (main): Do not deallocate the underlying node;
> servers deallocate nodes based only on the number of outstanding
> protids.
What is this supposed to be about? There is no protocol requirement that a
filesystem keep a send rig
12 matches
Mail list logo
