1 |
On 5/14/06, Dirk Heinrichs <ext-dirk.heinrichs@×××××.com> wrote: |
2 |
> > What I would really like to see is something like reiser4's plugin |
3 |
> > scheme brought up to the VFS layer in the kernel, so that any |
4 |
> > filesystem could gain transparent compression. |
5 |
> |
6 |
> Hmm, wouldn't that be a device mapper task, just like dm-crypt? |
7 |
|
8 |
I don't think so, because how would the filesystem know how many |
9 |
blocks are available to it? If I create a 10G filesystem on a 10G |
10 |
compressing dm that averages 2:1 compression, I could store 20G of |
11 |
files, but the filesystem would provide only 10G of space. Ok, so you |
12 |
create a 20G filesystem instead...now what happens if you store a |
13 |
bunch of already compressed files there, and run out of room on the dm |
14 |
volume before the filesystem thinks you should? My guess is Bad |
15 |
Things. |
16 |
|
17 |
But if the compression is done by the filesystem, it can know exactly |
18 |
how many real blocks a compressed file takes, so it can maintain it's |
19 |
accounting for free blocks appropriately. Thus I think the filesystem |
20 |
or VFS layer is the only sane place to implement any compression. |
21 |
|
22 |
-Richard |
23 |
|
24 |
-- |
25 |
gentoo-user@g.o mailing list |