headers
Lee Trager | 1 Dec 2008 22:02
Picon

Supported Kernels

According to the FAQ at http://btrfs.wiki.kernel.org/index.php/FAQ all
kernels downto 2.6.18 should be supported. I have tried to compile
against 2.6.18(Debian Kernel), 2.6.24(Debian Kernel), 2.6.26(Debian
Kernel), and 2.6.27(Ubuntu Kernel) and I have only been able to compile
successfully against 2.6.27. Is btrfs still trying to maintain backwards
compatibility with older version or is the focus on finilizing the on
disk format?

Thanks,

Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Oliver Mattos | 2 Dec 2008 00:49
Picon

Re: Partial allocation

Hi,

I presume that in the design of BTRFS, like most other filesystems, a
block on the underlying storage is either allocated (ie. to store
metadata or file data), or deallocated (possibly blank or containing
garbage left over, but the contents are irrelivant).

Does BTRFS have any system that could allow adding at a later point in
time a feature which would allow "weak" allocation of blocks, by which I
mean the block is allocated (ie. storing useful data), but if another
file needs to be written which has a higher priority and there are no
free blocks left, then the data will be replaced.

I could forsee uses for features like that as a cache - for example my
web browsing cache is not vital data, and as such doesn't need to use up
disk space, but it might as well use up any disk space that would
otherwise go unused.  The cache data can always be regenerated, so
loosing the data isn't a problem.

Other uses of the feature could be for persistant network caches (ie. to
store copies of remote files on the network can they can be accessed
faster locally), but again the cache data isn't critical to the
operation of the system, so could be stored in "weakly allocated"
blocks.  Further uses could be caches of compressed files (decompressed
versions of the same files are also saved in other blocks, and depending
on IO and CPU load either the compressed or decompressed version is
used).

>From a user-land perspective, these files could be created with a
special flag which specifies they are only "weakly allocated", which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Mattos | 2 Dec 2008 09:47
Picon

Weak Allocation

Hi,

I presume that in the design of BTRFS, like most other filesystems, a
block on the underlying storage is either allocated (ie. to store
metadata or file data), or deallocated (possibly blank or containing
garbage left over, but the contents are irrelivant).

Does BTRFS have any system that could allow adding at a later point in
time a feature which would allow "weak" allocation of blocks, by which I
mean the block is allocated (ie. storing useful data), but if another
file needs to be written which has a higher priority and there are 
no/not many alternate blocks readily available for use then the data
will be replaced.

I could forsee uses for features like that as a cache - for example my
web browsing cache is not vital data, and as such doesn't need to use up
disk space, but it might as well use up any disk space that would
otherwise go unused.  The cache data can always be regenerated, so
loosing the data isn't a problem.

Other uses of the feature could be for persistant network caches (ie. to
store copies of remote files on the network can they can be accessed
faster locally), but again the cache data isn't critical to the
operation of the system, so could be stored in "weakly allocated"
blocks.  Further uses could be caches of compressed files (decompressed
versions of the same files are also saved in other blocks, and depending
on IO and CPU load either the compressed or decompressed version is
used).

>From a user-land perspective, these files could be created with a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Mason | 2 Dec 2008 16:29
Picon
Favicon

New disk format pushed out

Hello everyone,

I've pushed out Josef's updates to make the checksum selectable at mkfs
time (right now there's only one choice, but we now have the disk format
bits for more).

This means both kernel and progs have a new disk format.  The format
will change a few more times this week as we try to hammer out the 1.0
format.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Oliver Mattos | 3 Dec 2008 01:32
Picon

Partial Allocation

Hi,

I presume that in the design of BTRFS, like most other filesystems, a
block on the underlying storage is either allocated (ie. to store
metadata or file data), or deallocated (possibly blank or containing
garbage left over, but the contents are irrelivant).

Does BTRFS have any system that could allow adding at a later point in
time a feature which would allow "weak" allocation of blocks, by which I
mean the block is allocated (ie. storing useful data), but if another
file needs to be written which has a higher priority and there are not
many free blocks left, then the data could be replaced.

I could forsee uses for features like that as a cache - for example my
web browsing cache is not vital data, and as such doesn't need to use up
disk space, but it might as well use up any disk space that would
otherwise go unused.  The cache data can always be regenerated, so
loosing the data isn't a problem.

Other uses of the feature could be for persistant network caches (ie. to
store copies of remote files on the network can they can be accessed
faster locally), but again the cache data isn't critical to the
operation of the system, so could be stored in "weakly allocated"
blocks.  Further uses could be caches of compressed files (decompressed
versions of the same files are also saved in other blocks, and depending
on IO and CPU load either the compressed or decompressed version is
used).

>From a user-land perspective, these files could be created with a
special flag which specifies they are only "weakly allocated", which
(Continue reading)

Permalink | Reply | 752 comments |
headers
Chris Mason | 3 Dec 2008 02:18
Picon
Favicon

Re: Partial Allocation

On Wed, 2008-12-03 at 00:32 +0000, Oliver Mattos wrote:
> Hi,
> 
> I presume that in the design of BTRFS, like most other filesystems, a
> block on the underlying storage is either allocated (ie. to store
> metadata or file data), or deallocated (possibly blank or containing
> garbage left over, but the contents are irrelivant).
> 
> Does BTRFS have any system that could allow adding at a later point in
> time a feature which would allow "weak" allocation of blocks, by which I
> mean the block is allocated (ie. storing useful data), but if another
> file needs to be written which has a higher priority and there are not
> many free blocks left, then the data could be replaced.
> 

It could be done, but I would expect that any userland facility that
wanted this kind of feature would want to maintain its own cache.  Files
that disappear tend to confuse all but a very small set of applications.

For now it doesn't have broad enough applications that I'm willing to
code it up before 1.0.  But if you want to dive in, please feel free.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Mason | 3 Dec 2008 19:19
Picon
Favicon

No btrfs conf call today

Hello everyone,

Sorry for the late notice, but I'm out sick today.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Josef Bacik | 4 Dec 2008 13:15
Picon
Favicon

Re: Partial Allocation

On Wed, Dec 03, 2008 at 12:32:56AM +0000, Oliver Mattos wrote:
> Hi,
> 
> I presume that in the design of BTRFS, like most other filesystems, a
> block on the underlying storage is either allocated (ie. to store
> metadata or file data), or deallocated (possibly blank or containing
> garbage left over, but the contents are irrelivant).
> 
> Does BTRFS have any system that could allow adding at a later point in
> time a feature which would allow "weak" allocation of blocks, by which I
> mean the block is allocated (ie. storing useful data), but if another
> file needs to be written which has a higher priority and there are not
> many free blocks left, then the data could be replaced.
> 
> I could forsee uses for features like that as a cache - for example my
> web browsing cache is not vital data, and as such doesn't need to use up
> disk space, but it might as well use up any disk space that would
> otherwise go unused.  The cache data can always be regenerated, so
> loosing the data isn't a problem.
> 
> Other uses of the feature could be for persistant network caches (ie. to
> store copies of remote files on the network can they can be accessed
> faster locally), but again the cache data isn't critical to the
> operation of the system, so could be stored in "weakly allocated"
> blocks.  Further uses could be caches of compressed files (decompressed
> versions of the same files are also saved in other blocks, and depending
> on IO and CPU load either the compressed or decompressed version is
> used).
> 
> >From a user-land perspective, these files could be created with a
(Continue reading)

Permalink | Reply | 751 comments |
headers
Liu Hui | 4 Dec 2008 15:08
Picon

[PATCH]Fix for map_private_extent_buffer to handle extent which is not page alignment

Hi,
Now, BTRFS only supports page alignment extent. But in
map_private_extent(), there are already some codes to handle the
extent which is not page alignment. For example,
map_private_extent_buffer also wants to handle a extent which is 7K
length properly. The problem is the codes are not enough, e.g. in the
following figure, map_private_extent_buffer can handle extent1, but it
can't take the right behavior to handle extent2. This patch fixs it.

PS:Please use the mono font to view the ASCII figures, thanks.

   |-extent1-|
+-----++-----+
|page1||page2|
+-----++-----+

|-extent2-|
+-----++-----+
|page1||page2|
+-----++-----+

--

-- 
Thanks & Best Regards
Liu Hui
--

diff --git a/extent_io.c b/extent_io.c
index c3dfe2a..cac47d1 100644
--- a/extent_io.c
+++ b/extent_io.c
(Continue reading)

Permalink | Reply | 2 comments |
headers
Liu Hui | 4 Dec 2008 15:21
Picon

Re: [PATCH]Fix for map_private_extent_buffer to handle extent which is not page alignment

There is a little problem with the first ASCII figure, here is the new one.
   |-extent1-|
+-----++-----+
|page1||page2|
+-----++-----+

Thanks,
Liu Hui

2008/12/4 Liu Hui <onlyflyer <at> gmail.com>:
> Hi,
> Now, BTRFS only supports page alignment extent. But in
> map_private_extent(), there are already some codes to handle the
> extent which is not page alignment. For example,
> map_private_extent_buffer also wants to handle a extent which is 7K
> length properly. The problem is the codes are not enough, e.g. in the
> following figure, map_private_extent_buffer can handle extent1, but it
> can't take the right behavior to handle extent2. This patch fixs it.
>
> PS:Please use the mono font to view the ASCII figures, thanks.
>
>   |-extent1-|
> +-----++-----+
> |page1||page2|
> +-----++-----+
>
> |-extent2-|
> +-----++-----+
> |page1||page2|
> +-----++-----+
(Continue reading)

Permalink | Reply | 1 comment |

Gmane