Commit fd689427 authored by Kirill Smelkov's avatar Kirill Smelkov

.

parent d27c89ee
...@@ -20,13 +20,17 @@ ...@@ -20,13 +20,17 @@
* *
* See COPYING file for full licensing terms. * See COPYING file for full licensing terms.
* See https://www.nexedi.com/licensing for rationale and options. * See https://www.nexedi.com/licensing for rationale and options.
*/
/* Header wendelin/bigfile/file.h provides BigFile and interfaces that
* particular BigFile implementations must provide.
* *
* ~~~~~~~~ * The interfaces are described in `struct bigfile_ops`.
* * A particular BigFile implementation must provide loadblk/storeblk and
* TODO description * optionally mmap_* methods.
* *
* Clients usually work with bigfiles via mapping files to memory - * Clients work with bigfiles via mapping files to memory - see
* see wendelin/bigfile/virtmem.h and BigFileH for details. XXX * wendelin/bigfile/virtmem.h and BigFileH for client-level API details.
*/ */
#include <stddef.h> #include <stddef.h>
...@@ -42,7 +46,7 @@ typedef struct VMA VMA; ...@@ -42,7 +46,7 @@ typedef struct VMA VMA;
/* BigFile base class /* BigFile base class
* *
* BigFile is a file of fixed size blocks. It knows how to load/store blocks * BigFile is a file of fixed size blocks. It knows how to load/store blocks
* to/from memory. Nothing else. XXX also mmap? * to/from memory. It can be also optionally memory mmaped.
* *
* Concrete file implementations subclass BigFile and define their file_ops. * Concrete file implementations subclass BigFile and define their file_ops.
*/ */
...@@ -80,32 +84,37 @@ struct bigfile_ops { ...@@ -80,32 +84,37 @@ struct bigfile_ops {
void (*release) (BigFile *file); void (*release) (BigFile *file);
// Overlaying /* Mmap overlaying
// *
// XXX text * Besides .loadblk and .storeblk a particular BigFile implementation can
* also optionally provide functions to setup read-only memory mappings
// wc mmap = * with BigFile data. If such functions are provided, virtmem might use
// * them to organize read access to BigFile data through the mappings and
// ┌──┐ ┌──┐ * without allocating RAM for read pages. RAM will still be allocated for
// │RW│ │RW│ ← dirty * dirtied pages that are layed over base data layer provided by the
// └──┘ └──┘ * mappings.
// + *
// ───────────────────────────────────────────── ← base * The major user of this functionality is wcfs - virtual filesystem that
// * provides access to ZBigFile data via OS-level files(*). The layering can be
// base = file view @ zconn.at => * schematically depicted as follows
// base = *
// ___ /@revA/bigfile/X * ┌──┐ ┌──┐
// __ /@revB/bigfile/X * │RW│ │RW│ ← dirty pages
// _ /@revC/bigfile/X * └──┘ └──┘
// + ... * +
// ─── ───── ────────────────────────── ───── /head/bigfile/X * ───────────────────────────────────────────── ← mmap'ed base data
// *
// XXX link to wcfs/client/wcfs.h * The functions to setup memory mappings are:
*
// - mmap_setup_read(vma, file[blk +blklen)) -> addr setup initial read-only mmap to serve vma * - mmap_setup_read(vma, file[blk +blklen)) -> addr setup initial read-only mmap to serve vma
// - remmap_blk_read(vma, file[blk]) remmap blk into vma again, after e.g. * - remmap_blk_read(vma, file[blk]) remmap blk into vma again, after e.g.
// RW dirty page was discarded * RW dirty page was discarded
// - munmap(vma) before VMA is unmapped * - munmap(vma) before VMA is unmapped
*
*
* (*) see wcfs/client/wcfs.h
*/
/* mmap_setup_read is called to setup new read-only mapping of file[blk +blklen). /* mmap_setup_read is called to setup new read-only mapping of file[blk +blklen).
* *
...@@ -140,12 +149,13 @@ struct bigfile_ops { ...@@ -140,12 +149,13 @@ struct bigfile_ops {
void* (*mmap_setup_read) (VMA *vma, BigFile *file, blk_t blk, size_t blklen); void* (*mmap_setup_read) (VMA *vma, BigFile *file, blk_t blk, size_t blklen);
// remmap_blk_read is called to remmap a block into vma again, after e.g. /* remmap_blk_read is called to remmap a block into vma again, after e.g.
// RW dirty page was discarded. * RW dirty page was discarded.
// *
// Called under virtmem lock. NOTE hard to rework to call with !virt_lock * Called under virtmem lock. NOTE hard to rework to call with !virt_lock
// *
// XXX error -> bug (must not fail) * XXX error -> bug (must not fail)
*/
int (*remmap_blk_read) (VMA *vma, BigFile *file, blk_t blk); int (*remmap_blk_read) (VMA *vma, BigFile *file, blk_t blk);
/* munmap is called when vma set up via mmap_setup_read is going to be unmapped. /* munmap is called when vma set up via mmap_setup_read is going to be unmapped.
......
...@@ -30,7 +30,19 @@ ...@@ -30,7 +30,19 @@
* marks modified pages as dirty. Dirty pages then can be on request either * marks modified pages as dirty. Dirty pages then can be on request either
* written out back to file or discarded. * written out back to file or discarded.
* *
* XXX update for wcfs. *
* Mmap overlaying
*
* A particular BigFile implementation can optionally provide functionality to
* mmap its data into memory. For BigFile handles opened in such mode, virtmem
* does not allocate RAM for read access and will only allocate RAM when pages
* are dirtied. The mode in which BigFile handle is opened is specified via
* fileh_open(flags=...).
*
* The major user of "mmap overlay" functionality is wcfs - virtual filesystem
* that provides access to ZBigFile data via OS-level files(*).
*
* (*) see wcfs/client/wcfs.h and wcfs/wcfs.go
*/ */
#include <stdint.h> #include <stdint.h>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment