* Premature ENOSPC only with zlib Compression
@ 2012-01-18 16:13 Mitch Harder
2012-01-20 18:55 ` Ahmet Inan
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Mitch Harder @ 2012-01-18 16:13 UTC (permalink / raw)
To: linux-btrfs
I have a Btrfs partition that is reliably reproducing premature ENOSPC
when restoring the disk from a tar file, but it is only happening with
zlib compression (lzo or no compression proceeds normally).
I've had the same issue at least back through the 3.1 kernel series,
and I've been having intermittent issues even further back.
I am currently using a 3.2.1 kernel merged with Chris' latest
integration branch.
I've performed about 12 trials trying to explore various combinations
of compress, compress-force, compress[-force]=[zlib,lzo] and
autodefrag.
If I use no compression, or if I explicitly declare lzo compression, I
don't receive the premature ENOSPC when untarring my restoration
archive to the empty partition.
If I don't specify compression (zlib is the default) or specify zlib,
I get consistent premature ENOSPC errors regardless of other
combinations.
I apologize if this is already general knowledge, but I couldn't see
where this has been posted to the list before.
As time allows, I will try to capture exactly where this ENOSPC is
being issued in btrfs by inserting WARN_ON's in my local version
where-ever ENOSPC is set.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-01-18 16:13 Premature ENOSPC only with zlib Compression Mitch Harder
@ 2012-01-20 18:55 ` Ahmet Inan
2012-02-08 21:01 ` Mitch Harder
2012-02-16 8:06 ` Ahmet Inan
2 siblings, 0 replies; 10+ messages in thread
From: Ahmet Inan @ 2012-01-20 18:55 UTC (permalink / raw)
To: Mitch Harder; +Cc: linux-btrfs
On Wed, Jan 18, 2012 at 5:13 PM, Mitch Harder
<mitch.harder@sabayonlinux.org> wrote:
> I have a Btrfs partition that is reliably reproducing premature ENOSPC
> when restoring the disk from a tar file, but it is only happening with
> zlib compression (lzo or no compression proceeds normally).
thank you very much for this info.
i did the same thing: compress=lzo
now i can do a full system installation to an fresh btrfs filesystem
without "--bwlimit 4096" to rsync again!
my kernel: vanilla 3.2.1
Ahmet
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-01-18 16:13 Premature ENOSPC only with zlib Compression Mitch Harder
2012-01-20 18:55 ` Ahmet Inan
@ 2012-02-08 21:01 ` Mitch Harder
2012-02-09 2:14 ` Liu Bo
2012-02-16 8:06 ` Ahmet Inan
2 siblings, 1 reply; 10+ messages in thread
From: Mitch Harder @ 2012-02-08 21:01 UTC (permalink / raw)
To: linux-btrfs
On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
<mitch.harder@sabayonlinux.org> wrote:
> I have a Btrfs partition that is reliably reproducing premature ENOSPC
> when restoring the disk from a tar file, but it is only happening with
> zlib compression (lzo or no compression proceeds normally).
>
> I've had the same issue at least back through the 3.1 kernel series,
> and I've been having intermittent issues even further back.
>
> I am currently using a 3.2.1 kernel merged with Chris' latest
> integration branch.
>
> I've performed about 12 trials trying to explore various combinations
> of compress, compress-force, compress[-force]=[zlib,lzo] and
> autodefrag.
>
> If I use no compression, or if I explicitly declare lzo compression, I
> don't receive the premature ENOSPC when untarring my restoration
> archive to the empty partition.
>
> If I don't specify compression (zlib is the default) or specify zlib,
> I get consistent premature ENOSPC errors regardless of other
> combinations.
>
> I apologize if this is already general knowledge, but I couldn't see
> where this has been posted to the list before.
>
> As time allows, I will try to capture exactly where this ENOSPC is
> being issued in btrfs by inserting WARN_ON's in my local version
> where-ever ENOSPC is set.
Some follow-up...
I've injected some debugging code to isolate when the ENOSPC is being
generated when using zlib compression.
When using zlib, I'm getting intermittent ENOSPC in the
may_commit_transaction() function in extent-tree.c at this point:
if (delayed_rsv->size < bytes) {
spin_unlock(&delayed_rsv->lock);
return -ENOSPC;
}
The typical values for (delayed_rsv->size < bytes) have been:
delayed_rsv->size ( = 0x60000) < bytes ( = 0x78000)
This typically occurs when unzipping a section of my backup that
contains lots of small files that are probably being mostly in-lined.
I don't see errors in this section when using lzo or no compression.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-02-08 21:01 ` Mitch Harder
@ 2012-02-09 2:14 ` Liu Bo
2012-02-09 20:29 ` Mitch Harder
0 siblings, 1 reply; 10+ messages in thread
From: Liu Bo @ 2012-02-09 2:14 UTC (permalink / raw)
To: Mitch Harder; +Cc: linux-btrfs
On 02/09/2012 05:01 AM, Mitch Harder wrote:
> On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
> <mitch.harder@sabayonlinux.org> wrote:
>> I have a Btrfs partition that is reliably reproducing premature ENOSPC
>> when restoring the disk from a tar file, but it is only happening with
>> zlib compression (lzo or no compression proceeds normally).
>>
>> I've had the same issue at least back through the 3.1 kernel series,
>> and I've been having intermittent issues even further back.
>>
>> I am currently using a 3.2.1 kernel merged with Chris' latest
>> integration branch.
>>
>> I've performed about 12 trials trying to explore various combinations
>> of compress, compress-force, compress[-force]=[zlib,lzo] and
>> autodefrag.
>>
>> If I use no compression, or if I explicitly declare lzo compression, I
>> don't receive the premature ENOSPC when untarring my restoration
>> archive to the empty partition.
>>
>> If I don't specify compression (zlib is the default) or specify zlib,
>> I get consistent premature ENOSPC errors regardless of other
>> combinations.
>>
>> I apologize if this is already general knowledge, but I couldn't see
>> where this has been posted to the list before.
>>
>> As time allows, I will try to capture exactly where this ENOSPC is
>> being issued in btrfs by inserting WARN_ON's in my local version
>> where-ever ENOSPC is set.
>
> Some follow-up...
>
> I've injected some debugging code to isolate when the ENOSPC is being
> generated when using zlib compression.
>
> When using zlib, I'm getting intermittent ENOSPC in the
> may_commit_transaction() function in extent-tree.c at this point:
>
> if (delayed_rsv->size < bytes) {
> spin_unlock(&delayed_rsv->lock);
> return -ENOSPC;
> }
>
> The typical values for (delayed_rsv->size < bytes) have been:
> delayed_rsv->size ( = 0x60000) < bytes ( = 0x78000)
>
> This typically occurs when unzipping a section of my backup that
> contains lots of small files that are probably being mostly in-lined.
>
> I don't see errors in this section when using lzo or no compression.
Hi Mitch,
Would you like to try this patch?
thanks,
liubo
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 8603ee4..d83b15e 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3483,28 +3483,34 @@ static int may_commit_transaction(struct btrfs_root *root,
if (force)
goto commit;
- /* See if there is enough pinned space to make this reservation */
- spin_lock(&space_info->lock);
- if (space_info->bytes_pinned >= bytes) {
+ if (space_info != delayed_rsv->space_info) {
+ /*
+ * For DATA:
+ * See if there is enough pinned space to make this reservation
+ */
+ spin_lock(&space_info->lock);
+ if (space_info->bytes_pinned < bytes) {
+ spin_unlock(&space_info->lock);
+ return -ENOSPC;
+ }
spin_unlock(&space_info->lock);
- goto commit;
- }
- spin_unlock(&space_info->lock);
-
- /*
- * See if there is some space in the delayed insertion reservation for
- * this reservation.
- */
- if (space_info != delayed_rsv->space_info)
- return -ENOSPC;
-
- spin_lock(&delayed_rsv->lock);
- if (delayed_rsv->size < bytes) {
+ } else {
+ /*
+ * For METADATA:
+ * See if there is enough space(pinned and delayed insertion)
+ * to make this reservation
+ */
+ spin_lock(&space_info->lock);
+ spin_lock(&delayed_rsv->lock);
+ if (space_info->bytes_pinned + delayed_rsv->size < bytes) {
+ spin_unlock(&delayed_rsv->lock);
+ spin_unlock(&space_info->lock);
+ return -ENOSPC;
+ }
spin_unlock(&delayed_rsv->lock);
- return -ENOSPC;
- }
- spin_unlock(&delayed_rsv->lock);
+ spin_unlock(&space_info->lock);
+ }
commit:
trans = btrfs_join_transaction(root);
if (IS_ERR(trans))
--
1.6.5.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-02-09 2:14 ` Liu Bo
@ 2012-02-09 20:29 ` Mitch Harder
0 siblings, 0 replies; 10+ messages in thread
From: Mitch Harder @ 2012-02-09 20:29 UTC (permalink / raw)
To: Liu Bo; +Cc: linux-btrfs
On Wed, Feb 8, 2012 at 8:14 PM, Liu Bo <liubo2009@cn.fujitsu.com> wrote=
:
> On 02/09/2012 05:01 AM, Mitch Harder wrote:
>> On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
>> <mitch.harder@sabayonlinux.org> wrote:
>>> I have a Btrfs partition that is reliably reproducing premature ENO=
SPC
>>> when restoring the disk from a tar file, but it is only happening w=
ith
>>> zlib compression (lzo or no compression proceeds normally).
>>>
>>> I've had the same issue at least back through the 3.1 kernel series=
,
>>> and I've been having intermittent issues even further back.
>>>
>>> I am currently using a 3.2.1 kernel merged with Chris' latest
>>> integration branch.
>>>
>>> I've performed about 12 trials trying to explore various combinatio=
ns
>>> of compress, compress-force, compress[-force]=3D[zlib,lzo] and
>>> autodefrag.
>>>
>>> If I use no compression, or if I explicitly declare lzo compression=
, I
>>> don't receive the premature ENOSPC when untarring my restoration
>>> archive to the empty partition.
>>>
>>> If I don't specify compression (zlib is the default) or specify zli=
b,
>>> I get consistent premature ENOSPC errors regardless of other
>>> combinations.
>>>
>>> I apologize if this is already general knowledge, but I couldn't se=
e
>>> where this has been posted to the list before.
>>>
>>> As time allows, I will try to capture exactly where this ENOSPC is
>>> being issued in btrfs by inserting WARN_ON's in my local version
>>> where-ever ENOSPC is set.
>>
>> Some follow-up...
>>
>> I've injected some debugging code to isolate when the ENOSPC is bein=
g
>> generated when using zlib compression.
>>
>> When using zlib, I'm getting intermittent ENOSPC in the
>> may_commit_transaction() function in extent-tree.c at this point:
>>
>> =A0 =A0 =A0 if (delayed_rsv->size < bytes) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&delayed_rsv->lock);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOSPC;
>> =A0 =A0 =A0 }
>>
>> The typical values for (delayed_rsv->size < bytes) have been:
>> delayed_rsv->size ( =3D 0x60000) < bytes ( =3D 0x78000)
>>
>> This typically occurs when unzipping a section of my backup that
>> contains lots of small files that are probably being mostly in-lined=
=2E
>>
>> I don't see errors in this section when using lzo or no compression.
>
> Hi Mitch,
>
> Would you like to try this patch?
>
> thanks,
> liubo
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 8603ee4..d83b15e 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -3483,28 +3483,34 @@ static int may_commit_transaction(struct btrf=
s_root *root,
> =A0 =A0 =A0 =A0if (force)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto commit;
>
> - =A0 =A0 =A0 /* See if there is enough pinned space to make this res=
ervation */
> - =A0 =A0 =A0 spin_lock(&space_info->lock);
> - =A0 =A0 =A0 if (space_info->bytes_pinned >=3D bytes) {
> + =A0 =A0 =A0 if (space_info !=3D delayed_rsv->space_info) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* For DATA:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* See if there is enough pinned spac=
e to make this reservation
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(&space_info->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (space_info->bytes_pinned < bytes) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&space_info=
->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOSPC;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spin_unlock(&space_info->lock);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto commit;
> - =A0 =A0 =A0 }
> - =A0 =A0 =A0 spin_unlock(&space_info->lock);
> -
> - =A0 =A0 =A0 /*
> - =A0 =A0 =A0 =A0* See if there is some space in the delayed insertio=
n reservation for
> - =A0 =A0 =A0 =A0* this reservation.
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 if (space_info !=3D delayed_rsv->space_info)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOSPC;
> -
> - =A0 =A0 =A0 spin_lock(&delayed_rsv->lock);
> - =A0 =A0 =A0 if (delayed_rsv->size < bytes) {
> + =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* For METADATA:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* See if there is enough space(pinne=
d and delayed insertion)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to make this reservation
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(&space_info->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(&delayed_rsv->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (space_info->bytes_pinned + delayed_=
rsv->size < bytes) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&delayed_rs=
v->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&space_info=
->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOSPC;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spin_unlock(&delayed_rsv->lock);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOSPC;
> - =A0 =A0 =A0 }
> - =A0 =A0 =A0 spin_unlock(&delayed_rsv->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&space_info->lock);
>
> + =A0 =A0 =A0 }
> =A0commit:
> =A0 =A0 =A0 =A0trans =3D btrfs_join_transaction(root);
> =A0 =A0 =A0 =A0if (IS_ERR(trans))
> --
> 1.6.5.2
>
>
Thanks for looking at this, but I'm still getting ENOSPC errors at the
same point after applying this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-01-18 16:13 Premature ENOSPC only with zlib Compression Mitch Harder
2012-01-20 18:55 ` Ahmet Inan
2012-02-08 21:01 ` Mitch Harder
@ 2012-02-16 8:06 ` Ahmet Inan
2012-02-16 10:31 ` Chris Samuel
2 siblings, 1 reply; 10+ messages in thread
From: Ahmet Inan @ 2012-02-16 8:06 UTC (permalink / raw)
To: Mitch Harder; +Cc: linux-btrfs
On Wed, Jan 18, 2012 at 5:13 PM, Mitch Harder
<mitch.harder@sabayonlinux.org> wrote:
> I have a Btrfs partition that is reliably reproducing premature ENOSPC
> when restoring the disk from a tar file, but it is only happening with
> zlib compression (lzo or no compression proceeds normally).
Ive just unsquashfs'ed an 5GiB image on a fresh btrfs and a much
faster System using:
compress=lzo,noatime
and got ENOSPC again :(
so it doesnt matter if lzo or zlib: ENOSPC with compression enabled!
my kernel: vanilla 3.2.5
for testing, i suggest making a squashfs of your whole system "/" and
unsquashfs that image into a new subvolume.
this really seems to trigger this ENOSPC problem, because it creates
the files fast enough.
Ahmet
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-02-16 8:06 ` Ahmet Inan
@ 2012-02-16 10:31 ` Chris Samuel
2012-02-16 15:05 ` Ahmet Inan
0 siblings, 1 reply; 10+ messages in thread
From: Chris Samuel @ 2012-02-16 10:31 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1: Type: Text/Plain, Size: 585 bytes --]
On Thursday 16 February 2012 19:06:52 Ahmet Inan wrote:
> and got ENOSPC again :(
>
> so it doesnt matter if lzo or zlib: ENOSPC with compression
> enabled!
>
> my kernel: vanilla 3.2.5
I know that there has been an ENOSPC fix go in to the 3.3 RC kernels
since the 3.2 release, any chance you'd be able to see if it still
happens with the current 3.3 RC ?
cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-02-16 10:31 ` Chris Samuel
@ 2012-02-16 15:05 ` Ahmet Inan
2012-02-16 17:55 ` Chris Mason
0 siblings, 1 reply; 10+ messages in thread
From: Ahmet Inan @ 2012-02-16 15:05 UTC (permalink / raw)
To: Chris Samuel; +Cc: linux-btrfs
On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel <chris@csamuel.org> wrote:
> On Thursday 16 February 2012 19:06:52 Ahmet Inan wrote:
>
>> and got ENOSPC again :(
>>
>> so it doesnt matter if lzo or zlib: ENOSPC with compression
>> enabled!
>>
>> my kernel: vanilla 3.2.5
>
> I know that there has been an ENOSPC fix go in to the 3.3 RC kernels
> since the 3.2 release, any chance you'd be able to see if it still
> happens with the current 3.3 RC ?
just tested 3.3.0-rc3, and it works like a charm!
but there are lots of issues with external packages not compiling with 3.3,
why i wont be able to deploy it to our systems here yet.
could this one bugfix be backported to 3.2?
here are some results from my unsquashfs'ing just to show how
awesome btrfs with lzo is. these results are _not_ from an ssd btw!
(spinning disks, rebooted between tests)
# time unsquashfs /dev/nbd0
Parallel unsquashfs: Using 8 processors
792630 inodes (870469 blocks) to write
[==================/] 870469/870469 100%
created 759645 files
created 67271 directories
created 27250 symlinks
created 5141 devices
created 0 fifos
Timing Results:
zlib:
real 6m38.586s
user 2m16.021s
sys 0m31.138s
lzo:
real 1m53.429s
user 1m55.622s
sys 0m46.664s
no compression:
real 1m16.975s
user 1m47.173s
sys 0m53.520s
complete system installation in under 5minutes, that simply rocks!
Ahmet
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-02-16 15:05 ` Ahmet Inan
@ 2012-02-16 17:55 ` Chris Mason
2012-02-17 16:34 ` Ahmet Inan
0 siblings, 1 reply; 10+ messages in thread
From: Chris Mason @ 2012-02-16 17:55 UTC (permalink / raw)
To: Ahmet Inan; +Cc: Chris Samuel, linux-btrfs
On Thu, Feb 16, 2012 at 04:05:40PM +0100, Ahmet Inan wrote:
> On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel <chris@csamuel.org> wrote:
> > On Thursday 16 February 2012 19:06:52 Ahmet Inan wrote:
> >
> >> and got ENOSPC again :(
> >>
> >> so it doesnt matter if lzo or zlib: ENOSPC with compression
> >> enabled!
> >>
> >> my kernel: vanilla 3.2.5
> >
> > I know that there has been an ENOSPC fix go in to the 3.3 RC kernels
> > since the 3.2 release, any chance you'd be able to see if it still
> > happens with the current 3.3 RC ?
>
> just tested 3.3.0-rc3, and it works like a charm!
>
> but there are lots of issues with external packages not compiling with 3.3,
> why i wont be able to deploy it to our systems here yet.
>
> could this one bugfix be backported to 3.2?
All of the btrfs patches in 3.3-rc are against 3.2 in my git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
>
> here are some results from my unsquashfs'ing just to show how
> awesome btrfs with lzo is. these results are _not_ from an ssd btw!
> (spinning disks, rebooted between tests)
Very nice ;)
-chris
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Premature ENOSPC only with zlib Compression
2012-02-16 17:55 ` Chris Mason
@ 2012-02-17 16:34 ` Ahmet Inan
0 siblings, 0 replies; 10+ messages in thread
From: Ahmet Inan @ 2012-02-17 16:34 UTC (permalink / raw)
To: Chris Mason, Ahmet Inan, Chris Samuel, linux-btrfs
On Thu, Feb 16, 2012 at 6:55 PM, Chris Mason <chris.mason@oracle.com> wrote:
> On Thu, Feb 16, 2012 at 04:05:40PM +0100, Ahmet Inan wrote:
>> On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel <chris@csamuel.org> wrote:
>> > On Thursday 16 February 2012 19:06:52 Ahmet Inan wrote:
>> >
>> >> and got ENOSPC again :(
>> >>
>> >> so it doesnt matter if lzo or zlib: ENOSPC with compression
>> >> enabled!
>> >>
>> >> my kernel: vanilla 3.2.5
>> >
>> > I know that there has been an ENOSPC fix go in to the 3.3 RC kernels
>> > since the 3.2 release, any chance you'd be able to see if it still
>> > happens with the current 3.3 RC ?
>>
>> just tested 3.3.0-rc3, and it works like a charm!
>>
>> but there are lots of issues with external packages not compiling with 3.3,
>> why i wont be able to deploy it to our systems here yet.
>>
>> could this one bugfix be backported to 3.2?
>
> All of the btrfs patches in 3.3-rc are against 3.2 in my git tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
thank you very much, it works as it should.
had to couse some traffic on kernel.org but finally i got a local linux repo!
is for-linus considered stable and can i pull regularly?
here what i did for those interested:
cd /usr/src/
rm linux
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux
cd linux
git checkout linux-3.2.y
git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus
cp /boot/config .config
make menuconfig
# look around, save and exit
make -j8
make modules_install
make install
and thats it, 3.2.6 stable kernel from git with latest for-linus btrfs from git
Ahmet
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-02-17 16:34 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-18 16:13 Premature ENOSPC only with zlib Compression Mitch Harder
2012-01-20 18:55 ` Ahmet Inan
2012-02-08 21:01 ` Mitch Harder
2012-02-09 2:14 ` Liu Bo
2012-02-09 20:29 ` Mitch Harder
2012-02-16 8:06 ` Ahmet Inan
2012-02-16 10:31 ` Chris Samuel
2012-02-16 15:05 ` Ahmet Inan
2012-02-16 17:55 ` Chris Mason
2012-02-17 16:34 ` Ahmet Inan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).