Re: Page sharing: filesystem on block device

To be clear I'm asking as an end user of mach, and I'm interested in how to
write a filesystem that presumably interacts with a block device.

On Thu, May 16, 2019 at 8:44 AM Raymond Jennings <[email protected]> wrote:

> 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
>>
>