Block cache #113

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

Projects

None yet

5 participants

@nfeske
Genode Labs member

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).

@m-stein
Genode Labs member

I'd suggest a readahead strategy also.

@abique

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 ?

@nfeske
Genode Labs member

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.

@nfeske
Genode Labs member

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

@skalk skalk was assigned Nov 5, 2013
@skalk skalk added a commit to skalk/genode that referenced this issue Nov 22, 2013
@skalk skalk 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
@skalk
Genode Labs member

@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?

@nfeske
Genode Labs member

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

@skalk skalk added a commit to skalk/genode that referenced this issue Nov 22, 2013
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Nov 25, 2013
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Nov 25, 2013
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Dec 2, 2013
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Dec 3, 2013
@skalk skalk 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
@skalk skalk added a commit to skalk/genode that referenced this issue Feb 5, 2014
@skalk skalk 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
@skalk skalk added a commit to skalk/genode that referenced this issue Feb 5, 2014
@skalk skalk 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
@skalk
Genode Labs member

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

@skalk skalk added the fixed label Feb 5, 2014
@skalk skalk added a commit to skalk/genode that referenced this issue Feb 5, 2014
@skalk skalk 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
@skalk skalk added a commit to skalk/genode that referenced this issue Feb 5, 2014
@skalk skalk 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
@chelmuth
Genode Labs member

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);
    }
}
@skalk skalk added a commit that referenced this issue Feb 5, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 5, 2014
@skalk skalk 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
@skalk
Genode Labs member

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

@chelmuth
Genode Labs member

I used nova_x86_64.

@skalk
Genode Labs member

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.

@skalk skalk added a commit that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit to skalk/genode that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit to skalk/genode that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 6, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 25, 2014
@skalk skalk 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
@skalk skalk added a commit that referenced this issue Feb 25, 2014
@skalk skalk 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
@skalk skalk added a commit that closed this issue Feb 28, 2014
@skalk skalk 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
@skalk skalk closed this in ca51311 Feb 28, 2014
@cproc cproc pushed a commit to cproc/genode that referenced this issue May 12, 2014
@skalk skalk 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
8106a2e
@cproc cproc pushed a commit to cproc/genode that referenced this issue May 12, 2014
@skalk skalk 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
1c86069
@cproc cproc pushed a commit to cproc/genode that referenced this issue May 12, 2014
@skalk skalk 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
26ac38a
@cproc cproc pushed a commit to cproc/genode that referenced this issue May 12, 2014
@skalk skalk 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
e1b8694
@cproc cproc pushed a commit to cproc/genode that referenced this issue May 12, 2014
@skalk skalk 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
ad792b9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment