Skip to content
This repository

Block cache #113

Closed
nfeske opened this Issue February 14, 2012 · 11 comments

5 participants

Norman Feske Stefan Kalkowski Martin Stein Alexandre Bique Christian Helmuth
Norman Feske
Owner

Currently, there exists only the iso9660 server that is able to cache block accesses. A generic solution for caching block-device accesses would be nice. One suggestion is a component that requests a block session (routed to a block device driver) as back end and also announces a block service (front end) itself. Such a block-cache server waits for requests at the front end and forwards them to the back end. But it uses its own memory to cache blocks.

The first version could support only read-only block devices (such as CDROM) by caching the results of read accesses. In this version, we already need an eviction strategy that kicks in once the block cache gets saturated. For a start this could be FIFO or LRU (least recently used).

A more sophisticated version would support write accesses, too. Here we need a way to sync blocks to the back end at regular intervals in order to guarantee that all block-write accesses are becoming persistent after a certain time. We would also need a way to explicitly flush the block cache (i.e., when the front-end block session gets closed).

Martin Stein
Collaborator

I'd suggest a readahead strategy also.

Alexandre Bique

Will mmap work directly with the block cache ? Will mmap be supported by Genode ?

And so madvise() and fadvise() will also need to talk with this daemon ?

Norman Feske
Owner

On block-level, there is no mmap facility. The block-session interface is a shared-memory-based packet stream interface that resembles the semantics of block-device accesses.

On file-system-level, we will certainly support a facility similar to mmap (maybe not in the first version though). The mmap-like-mechanism will be based on Genode's dataspace concept. That is, you will be able to request a dataspace for a specific file. In return, you receive a dataspace capability. Using this capability, the dataspace can be locally mapped (similar to how mmap is used to locally map a file), or it could be shared with another process by sending the capability as RPC argument.

Norman Feske
Owner

@skalk would you like to assign the issue to yourself?

Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode November 22, 2013
Stefan Kalkowski block_session: extend interface with sync() call
To support components, which implement the block session's server side
rpc object, and which doesn't write data to their device backend immediately,
an additional synchronization call is needed. Thereby, clients like for
instance a file system can tell these components, when a synchronization is
required.

Ref #113
b79d84b
Stefan Kalkowski
Collaborator

@nfeske: would you mind to put above commit to staging, so it might be part of the November release?
@cnuke: maybe you could adapt your recent FUSE work to use the new sync() call, as long as it reaches staging?

Stefan Kalkowski skalk referenced this issue from a commit November 22, 2013
Commit has since been removed from the repository and is no longer available.
Norman Feske
Owner

Thanks @skalk. I pushed the sync API to staging.

Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode November 22, 2013
Stefan Kalkowski block: eliminate thread in generic block_component
Instead of using an additional thread in each Session_component of a
block server, which uses the generic block component and driver classes,
replace it with signal dispatchers.

Ref #113
742310d
Stefan Kalkowski skalk referenced this issue from a commit November 22, 2013
Stefan Kalkowski block_session: extend interface with sync() call
To support components, which implement the block session's server side
rpc object, and which doesn't write data to their device backend immediately,
an additional synchronization call is needed. Thereby, clients like for
instance a file system can tell these components, when a synchronization is
required.

Ref #113
7353a82
Stefan Kalkowski skalk referenced this issue from a commit November 22, 2013
Stefan Kalkowski block_session: extend interface with sync() call
To support components, which implement the block session's server side
rpc object, and which doesn't write data to their device backend immediately,
an additional synchronization call is needed. Thereby, clients like for
instance a file system can tell these components, when a synchronization is
required.

Ref #113
50d73e7
Stefan Kalkowski skalk referenced this issue from a commit November 28, 2013
Commit has since been removed from the repository and is no longer available.
Stefan Kalkowski skalk referenced this issue from a commit December 02, 2013
Commit has since been removed from the repository and is no longer available.
Stefan Kalkowski skalk referenced this issue from a commit November 22, 2013
Stefan Kalkowski block: eliminate thread in generic block_component
Instead of using an additional thread in each Session_component of a
block server, which uses the generic block component and driver classes,
replace it with signal dispatchers.

Ref #113
689a246
Stefan Kalkowski skalk referenced this issue from a commit November 22, 2013
Stefan Kalkowski block: eliminate thread in generic block_component
Instead of using an additional thread in each Session_component of a
block server, which uses the generic block component and driver classes,
replace it with signal dispatchers.

Ref #113
5a4cb7f
Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode February 05, 2014
Stefan Kalkowski os: handle ipc error in server framework
When using the server framework, it might happen that the main thread
tries to forward a signal to the entrypoint, while the context of that
signal is already destroyed. In that case the main thread will get an
ipc error exception as result.

Related to #113
e6babf9
Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
37dc0b2
Stefan Kalkowski
Collaborator

Only commit e6babf9 and 37dc0b2 are left to solve the issue.

Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode February 05, 2014
Stefan Kalkowski os: handle ipc error in server framework
When using the server framework, it might happen that the main thread
tries to forward a signal to the entrypoint, while the context of that
signal is already destroyed. In that case the main thread will get an
ipc error exception as result.

Related to #113
f7bca45
Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
cd0b400
Christian Helmuth
Owner

The cache seems to work, but the test case sometimes breaks with

no RM attachment (READ pf_addr=101c08 pf_ip=10066c7 from a0efefc6 blk_srv_ep)
virtual void Genode::Signal_session_component::submit(Genode::Signal_context_capability, unsigned int): invalid signal-context capability
static void Genode::Pager_object::_page_fault_handler(): unhandled page fault, 'pager:blk_srv_ep' address=0x101c08 ip=0x10066c7

This is somewhere in os/src/test/blk/srv/main.cc:45

void handler(unsigned)
{
    while (!_packets.empty()) {
        Block::Packet_descriptor p = _packets.get();
        session->ack_packet(p);
    }
}
Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski os: handle ipc error in server framework
When using the server framework, it might happen that the main thread
tries to forward a signal to the entrypoint, while the context of that
signal is already destroyed. In that case the main thread will get an
ipc error exception as result.

Related to #113
472a004
Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
90da711
Stefan Kalkowski
Collaborator

@chelmuth what platform triggered that pagefault? I've tested on top of Fiasco.OC and OKL4 x86_32.

Christian Helmuth
Owner

I used nova_x86_64.

Stefan Kalkowski
Collaborator

Ok, thanks for helping me to find the root cause! So it's a race in the destruction process of the test-blk_srv. Nevertheless, it unveils a weakness of the block driver API. As a consequence a block driver should be explicitly (not implicitly via a pointer) informed about creating/destroying sessions from clients.

Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski os: handle ipc error in server framework
When using the server framework, it might happen that the main thread
tries to forward a signal to the entrypoint, while the context of that
signal is already destroyed. In that case the main thread will get an
ipc error exception as result.

Related to #113
537b247
Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
9a3f41f
Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
fa75ab0
Stefan Kalkowski skalk referenced this issue from a commit in skalk/genode February 06, 2014
Stefan Kalkowski block: prevent from dereferencing invalid pointers
Until now, block drivers had to deal with a pointer to the client
session component, e.g.: to acknowledge block packets already processed.
When a session was closed, the driver object wasn't informed explicitly,
which leads to defensive programming, or lastly to a race-condition in
test-blk-srv. To prevent from this class of errors, the pointer is now
private to the generic block driver base class, and not accessible to
the concrete driver implementation. Moreover, the driver gets explicitly
informed when a session got invalidated.

Ref #113
2239c60
Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
e54f7fe
Stefan Kalkowski skalk referenced this issue from a commit February 06, 2014
Stefan Kalkowski block: prevent from dereferencing invalid pointers
Until now, block drivers had to deal with a pointer to the client
session component, e.g.: to acknowledge block packets already processed.
When a session was closed, the driver object wasn't informed explicitly,
which leads to defensive programming, or lastly to a race-condition in
test-blk-srv. To prevent from this class of errors, the pointer is now
private to the generic block driver base class, and not accessible to
the concrete driver implementation. Moreover, the driver gets explicitly
informed when a session got invalidated.

Ref #113
0c3e3da
Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
418717a
Stefan Kalkowski skalk referenced this issue from a commit February 06, 2014
Stefan Kalkowski block: prevent from dereferencing invalid pointers
Until now, block drivers had to deal with a pointer to the client
session component, e.g.: to acknowledge block packets already processed.
When a session was closed, the driver object wasn't informed explicitly,
which leads to defensive programming, or lastly to a race-condition in
test-blk-srv. To prevent from this class of errors, the pointer is now
private to the generic block driver base class, and not accessible to
the concrete driver implementation. Moreover, the driver gets explicitly
informed when a session got invalidated.

Ref #113
46f405f
Stefan Kalkowski skalk referenced this issue from a commit February 05, 2014
Stefan Kalkowski os: handle ipc error in server framework
When using the server framework, it might happen that the main thread
tries to forward a signal to the entrypoint, while the context of that
signal is already destroyed. In that case the main thread will get an
ipc error exception as result.

Related to #113
0bc012e
Stefan Kalkowski skalk referenced this issue from a commit February 06, 2014
Stefan Kalkowski block: prevent from dereferencing invalid pointers
Until now, block drivers had to deal with a pointer to the client
session component, e.g.: to acknowledge block packets already processed.
When a session was closed, the driver object wasn't informed explicitly,
which leads to defensive programming, or lastly to a race-condition in
test-blk-srv. To prevent from this class of errors, the pointer is now
private to the generic block driver base class, and not accessible to
the concrete driver implementation. Moreover, the driver gets explicitly
informed when a session got invalidated.

Ref #113
eeb2d95
Stefan Kalkowski skalk closed this issue from a commit February 05, 2014
Stefan Kalkowski block: cache between one client and one device
This block cache component acts as a block device for a single client.
It uses fixed 4K blocks as caching granularity, thereby implicitly reads
ahead whenever a client requests lesser amount of blocks. Currently,
it only supports a least-recently-used replacement policy.

Fixes #113
ca51311
Stefan Kalkowski skalk closed this in ca51311 February 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.