> 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
This patch makes tmpfs work. Well, mostly. If you attempt to create
files too quickly on the tmpfs (e.g. extract a tar file), vm_map (when
passed memory objects, it works fine mapping anonymously) maps bad
memory regions into the server address space which cause the server to
stall during the me
13 matches
Mail list logo
