[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Page sharing: filesystem on block device
From: |
Richard Braun |
Subject: |
Re: Page sharing: filesystem on block device |
Date: |
Thu, 16 May 2019 17:28:32 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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 bug-hurd@gnu.org since this list is for end user help.
--
Richard Braun