Hello, Just a quick answer: data caching is typically managed by the mach memory objects, so you'll want to read about them.
Samuel Raymond Jennings, le jeu. 16 mai 2019 08:58:07 -0700, a ecrit: > (referred here by Richard Braun <[1]rbr...@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:rbr...@sceen.net
