summaryrefslogtreecommitdiff
path: root/Caching.mdwn
blob: a12415486a16ba04f0ebcd8ec3eedf233c97da17 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
# Caching, targets, data placement

bcachefs can be configured for writethrough, writeback, and writearound
caching, as well as other more specialized setups.

The basic operations (and options) to consider are:

 - Where foreground writes go
 - Where data is moved to in the background
 - Where data is promoted to on read

## Target options and disk labels

To configure caching, we first need to be able to refer to one or more devices;
referring to more than one device requires labelling devices. Labels are paths,
with dot delimiters, which allows devices to be grouped into a heirarchy.

For example, formatting with the following labels

  bcachefs format				\
	--label=ssd.ssd1	/dev/sda1	\
	--label=ssd.ssd2	/dev/sdb1	\
	--label=hdd.hdd1	/dev/sdc1	\
	--label=hdd.hdd2	/dev/sdd1	\

Then target options could refer to any of:

	`--foreground_target=/dev/sda1`
	`--foreground_target=ssd	`(both sda1 and sdb1)
	`--foreground_target=ssd.ssd1	`(alias for sda1)

## Caching:

For writeback caching (the most common configuration), we want foreground
writes to go to the fast device, data to be moved in the background to the slow
device, and additionally any time we read if the data isn't already on the fast
device we want a copy to be stored there. Continuing with the previous example,
you'd use the following options:

	--foreground_target=ssd
	--background_target=hdd
	--promote_target=ssd

The rebalance thread will continually move data to the `background_target`
device(s). When doing so, the copy on the original device will be kept but
marked as cached; also, when promoting data to the promote target the
newly-written copy will be marked as cached.

Cached data is evicted as-needed, in standard LRU fashion.

## `data_allowed`

The target options are best-effort; if the specified devices are full the
allocator will fall back to allocating from any device that has space.

The per-device `data_allowed` option can be used to restrict devices to be used
for only journal, btree, or user data, and this is a hard restriction.

## `durabiliity`

Some devices may already have internal redundancy, e.g. a hardware raid
controller. The `durability` option may be used to indicate that a replicas on
a device should count as being worth `n` replicas towards the desired total.

Also, specifying `--durability=0` allows a device to be used for true
writethrough caching, where we consider a device to be untrusted: allocations
will ensure that the device can be yanked at any time without losing data.