[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Page sharing between a block device and a mounted file system?

From: Raymond Jennings
Subject: Re: Page sharing between a block device and a mounted file system?
Date: Thu, 16 May 2019 10:35:07 -0700

Already did, that's why I'm asking.

The question is, if i have a task serving a block device, which has a task serving a filesystem as a client, how do I keep the same page of data for a file block from being stored redundantly as two separate pages, perhaps in two separate memory objects? 

On Thu, May 16, 2019 at 9:42 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:

Just a quick answer: data caching is typically managed by the mach
memory objects, so you'll want to read about them.


Raymond Jennings, le jeu. 16 mai 2019 08:58:07 -0700, a ecrit:
> (referred here by Richard Braun <[1]rbraun@sceen.net>)
> 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.
> References:
> [1] mailto:rbraun@sceen.net

reply via email to

[Prev in Thread] Current Thread [Next in Thread]