Re: Page sharing: filesystem on block device

Wait, do you mean "end user" of HURD, as opposed to the mach microkernel?

On Thu, May 16, 2019 at 8:28 AM Richard Braun <[email protected]> wrote:

> On Thu, May 16, 2019 at 07:16:59AM -0700, Raymond Jennings wrote:
> > So um...I may be totally missing the mark on this but if I have one task
> > running a file system and another task managing a block device mounted as
> > that file system, how does one manage a file in such a way that it won't
> > store data in memory redundantly that is also stored in the block device?
> >
> > Criteria that I'm guessing at:
> >
> > * The file needs to be mmap'able as well as accepting read/write requests
> > * The file is stored on the block device at locations determined by the
> > file's inode/extent tree
> > * The block device itself presumably can also be mmap'ed and accept
> > read/write requests, including to the same area of the "disk" that the
> file
> > data occupies
> > * The same data, and presumably, the same pages in memory, are being used
> > to cache both
> > * A read or write in one will reflect immediately in the other
> >
> > I must admit that I have no idea beyond the theoretical stuff gleanable
> > from the mach reference guide how this would work.
> >
> > As a thought exercise I'm trying to design my own microkernel inspired by
> > mach so I'm curious how one would prevent redundancy or inconsistency in
> > this sort of scenario.
> >
> > By contrast, I'm assuming that the file's metadata itself (extent trees,
> > directory listings, and so on) would just be read/write direct to the
> block
> > device without worrying about being "aliased" from the file itself.
> Ditto
> > if the file is accessed/mmap'ed uncompressed, but stored in a compressed
> > form on the block device.
>
> Resend to [email protected] since this list is for end user help.
>
> --
> Richard Braun
>