[haiku-development] Re: Do optional packages need to include everything they do? [...]
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 03 Sep 2009 00:58:53 +0200
On 2009-09-02 at 03:24:16 [+0200], Michael Lotz <mmlr@xxxxxxxx> wrote:
[...]
> > For the write overlay, I would expect the io() hook to work like
> > this:
> >
> > * A write request should be handled completely and synchronously by
> > the
> > hook. All data is just copied.
> >
> > * A read requests, if the file has not been written to yet, shall be
> > passed
> > straight to the underlying layer.
> >
> > * A read request, if the file has already been written to, needs to
> > be
> > processed by the hook:
> > - The request might not intersect with the modified data range, so
> > it can
> > be passed straight to the underlying layer.
> > - The request might be fully covered by modified data, so it can be
> > handled completely (synchronously), by copying out the respective
> > data.
> > - The request might be partially covered by modified data, in which
> > case
> > the covered ranges need to be served synchronously and sub-
> > requests need
> > to be created for the not-covered ranges and be forwarded to the
> > underlying layer. An optimization is possible when the beginning
> > or the
> > end of the range is covered: then that part could be handled
> > synchronously, the request be adjusted and passed on to the
> > underlying
> > layer.
>
> Understood and implemented pretty much exactly that way in r32900. It
> really was the same for read/write and read_pages/write_pages. They all
> use the same backend now, just the method of filling buffers depends on
> the type of hook called (IORequest::CopyData() for IO, direct memcpy
> otherwise).
The io() hook (should better be renamed to pages_io()) supersedes the
{read,write}_pages() hook. The major difference is that it is asynchronous,
though.
> > I don't know how the write overlay is implemented, but to keep things
> > simple it could just fully cache a file when first written to, to
> > avoid the
> > somewhat unhandy partially covered reads. That's seriously suboptimal
> > when
> > only small parts of large files are changed, but I don't think that's
> > a
> > particularly common case for the installer CD boot (probably not even
> > for a
> > live CD).
>
> It turned out not to be a problem at all. I've already implemented
> reading in the write_overlay to linearly fill buffers, alternating
> between write_buffers and filling gaps using the underlaying
> filesystem. This concept seems pretty optimal to me and now also works
> for IO by creating subrequests for the gaps that are then handed over
> to the underlaying filesystem.
>
> > Note, that when creating sub-requests for an IORequest you might need
> > to
> > associate an iteration and/or finished cookie and hook with the
> > request.
> > You'll have to replace the original cookie, but save it first and
> > later
> > call the original hooks, in such a case. For reference:
> > do_iterative_fd_io() (in vfs_request_io.cpp) does exactly that.
>
> I didn't do that, and it seems to work as expected, so I assumed it
> wasn't necessary in how I've implemented it. It's possible that I'm
> missing something though.
Since you're creating and executing the subrequests synchronously, that's
indeed not necessary. It is potentially slower than firing up the
subrequests asynchronously, though. I guess partially modified existing
files will be rather rare in the installation/live CD cases, so this
probably doesn't matter.
On 2009-09-02 at 14:25:57 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> "Michael Lotz" <mmlr@xxxxxxxx> wrote:
> > So far I haven't encountered that situation, but I see what you are
> > getting at. How would the attribute_overlay be able to tell if a node
> > is in fact an attribute though?
>
> That won't easily be possible, I'm afraid - when you stat the
> attribute, it will have an inode number differing from its parent, but
> it's hard to tell on the fly, especially since this can change with any
> write to an attribute (the node's name can even push other attributes
> out of the small data space).
Besides, the VFS will be sabotaging such checks, since all *_stat_*()
functions should always fill in the st_dev and st_ino fields with the
values for the respective vnode, so e.g. a vfs_stat_vnode() on an attribute
node will give you the respective ID for the attribute node.
The st_mode field OTOH might identify the node as an attribute, if the type
is set to S_ATTR by the file system.
> Since there is no asynchronous I/O interface for userland, we could
> prevent attributes from being mmaped which should make sure that they
> aren't accessed like that for now.
Although that would be kind of funny, one cannot mmap() attributes ATM.
Calling mmap() on an attribute FD will map the attribute's file instead.
CU, Ingo
Other related posts:
