blob: c568438e57b8a81648accf488ae9453f40e343d8 (
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
68
69
70
71
72
|
#TODO
## Kernel developers
### Current priorities
* Replication
* Compression is almost done: it's quite thoroughly tested, the only remaining
issue is a problem with copygc fragmenting existing compressed extents that
only breaks accounting.
* NFS export support is almost done: implementing i_generation correctly
required some new transaction machinery, but that's mostly done. What's left
is implementing a new kind of reservation of journal space for the new, long
running transactions.
### Other
* When we're using compression, we end up wasting a fair amount of space on
internal fragmentation because compressed extents get rounded up to the
filesystem block size when they're written - usually 4k. It'd be really nice
if we could pack them in more efficiently - probably 512 byte sector
granularity.
On the read side this is no big deal to support - we have to bounce
compressed extents anyways. The write side is the annoying part. The options
are:
* Buffer up writes when we don't have full blocks to write? Highly
problematic, not going to do this.
* Read modify write? Not an option for raw flash, would prefer it to not be
our only option
* Do data journalling when we don't have a full block to write? Possible
solution, we want data journalling anyways
* Inline extents - good for space efficiency for both small files, and
compression when extents happen to compress particularly well.
* Full data journalling - we're definitely going to want this for when the
journal is on an NVRAM device (also need to implement external journalling
(easy), and direct journal on NVRAM support (what's involved here?)).
Would be good to get a simple implementation done and tested so we know what
the on disk format is going to be.
### Low priority
* NOCOW
### Optional
(Will not be implemented by the lead developer.)
* It is possible to add bcache functionality to bcachefs.
If there is someone who wishes to implement this it would be an ok addition.
However using it as a filesystem should still be better.
## Developers
* bcachefs-tools needs some fleshing out in the --help department
## Users
* Benchmark bcachefs performance on different configurations:
(Note that these tests will have to be repeated in the future.)
* SSD
* HDD
* SSD + HDD
* Update the website / Documentation
* Ask questions (so and we can update the documentation / website).
|
