[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: Richard Braun
Subject: Re: Page sharing between a block device and a mounted file system?
Date: Sat, 18 May 2019 21:39:32 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, May 16, 2019 at 08:58:07AM -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.

You could take a look at the ext2fs translator.

Although I don't see the difficulty here. The file system should be
the only server to cache file data in the page cache, and should
merely use direct access to the block device.

Richard Braun

reply via email to

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