summaryrefslogtreecommitdiff
path: root/FuturePlans.mdwn
blob: 6561d92a4cfe3677c6d988d9abbd0597d5bb1b21 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
The following future plans are no longer accurate.
If you wish to use these feature take a look at bcachefs.

Further off, there's plans to use Bcache's index to implement overcommited storage.
If you're familiar with LVM, it works by allocating logical volumes in units of 4 mb extents;
thus you can arbitrarily create and resize LVs. But when you create an LV you have to fully allocate its storage,
regardless of whether it'll ever be written to. If you've ever managed servers with lots of random LVs,
you've probably experienced first hand how much of a pain it is to keep track of how much free space you have,
resize LVs when the filesystems fill up, etc. - not to mention the huge amount of space that typically gets wasted because you really don't want filesystems to fill up. 

But all the work has already been done in Bcache for allocating on demand,
and maintaining the index while it's in use - and by using the same index for cached data and the volumes themselves,
there will be approximately zero extra runtime overhead. You'll be able to create petabyte sized filesystems with a tiny amount of real storage,
resize them arbitrarily, and be able to see exactly how much space you're using. Reading from newly created volumes also won't return old data;
sectors that haven't previously been written to will return 0s. This was actually the primary motivation for this feature - for shared hosting,
you don't want customers to be able to see other people's data. 

There's also been quite a bit of interest in tiered storage. If you've got a truly large amount of storage, it may be beneficial to have a really large RAID60 of large 7200 rpm drives,
and a smaller RAID10 of 15k rpm SAS drives. Nobody wants to manually manage what goes where - and keep track of what data gets accessed the most - so if you could use it as one large pool,
and have data migrate between them automatically, so much the better. Once overcommited storage is implemented, tiered storage should actually be quite easy to add.