diff options
author | Brian Behlendorf <[email protected]> | 2011-02-03 10:34:05 -0800 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2011-02-10 09:27:21 -0800 |
commit | c0d35759c5ab1abaa6b72062cc4ecd0d86628de8 (patch) | |
tree | 203c0a9e95db5121b8c28b23737cf19523588dcb /include | |
parent | cc5f931cfd623c50f283fa5cf1bc21cfd7e5c703 (diff) |
Add mmap(2) support
It's worth taking a moment to describe how mmap is implemented
for zfs because it differs considerably from other Linux filesystems.
However, this issue is handled the same way under OpenSolaris.
The issue is that by design zfs bypasses the Linux page cache and
leaves all caching up to the ARC. This has been shown to work
well for the common read(2)/write(2) case. However, mmap(2)
is problem because it relies on being tightly integrated with the
page cache. To handle this we cache mmap'ed files twice, once in
the ARC and a second time in the page cache. The code is careful
to keep both copies synchronized.
When a file with an mmap'ed region is written to using write(2)
both the data in the ARC and existing pages in the page cache
are updated. For a read(2) data will be read first from the page
cache then the ARC if needed. Neither a write(2) or read(2) will
will ever result in new pages being added to the page cache.
New pages are added to the page cache only via .readpage() which
is called when the vfs needs to read a page off disk to back the
virtual memory region. These pages may be modified without
notifying the ARC and will be written out periodically via
.writepage(). This will occur due to either a sync or the usual
page aging behavior. Note because a read(2) of a mmap'ed file
will always check the page cache first even when the ARC is out
of date correct data will still be returned.
While this implementation ensures correct behavior it does have
have some drawbacks. The most obvious of which is that it
increases the required memory footprint when access mmap'ed
files. It also adds additional complexity to the code keeping
both caches synchronized.
Longer term it may be possible to cleanly resolve this wart by
mapping page cache pages directly on to the ARC buffers. The
Linux address space operations are flexible enough to allow
selection of which pages back a particular index. The trick
would be working out the details of which subsystem is in
charge, the ARC, the page cache, or both. It may also prove
helpful to move the ARC buffers to a scatter-gather lists
rather than a vmalloc'ed region.
Additionally, zfs_write/read_common() were used in the readpage
and writepage hooks because it was fairly easy. However, it
would be better to update zfs_fillpage and zfs_putapage to be
Linux friendly and use them instead.
Diffstat (limited to 'include')
-rw-r--r-- | include/sys/zfs_znode.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/sys/zfs_znode.h b/include/sys/zfs_znode.h index 53bd18109..9d12a118e 100644 --- a/include/sys/zfs_znode.h +++ b/include/sys/zfs_znode.h @@ -210,6 +210,7 @@ typedef struct znode { sa_handle_t *z_sa_hdl; /* handle to sa data */ boolean_t z_is_sa; /* are we native sa? */ boolean_t z_is_zvol; /* are we used by the zvol */ + boolean_t z_is_mapped; /* are we mmap'ed */ struct inode z_inode; /* generic vfs inode */ } znode_t; |