On Tue, 14 Feb 2012, Timo Nentwig wrote:
Date: Tue, 14 Feb 2012 18:37:16 +0100 (CET)
From: Timo Nentwig
To: linux-btrfs@vger.kernel.org
Subject: Re: can't read superblock (but could mount)
On Mon, 13 Feb 2012, Chris Mason wrote:
btrfs-debug-tree -b 9872289792 /dev/xxx
Hm, just did it ag
Just to add another data point, I built Chris Mason's 'snappy' branch
from git.kernel.org as-is (a 3.2.0 kernel plus the snappy patches)
with no additional patches.
This 3.2.0 snappy kernel also exhibits the problem copying the kernel
sources to a snappy-compressed partition.
--
To unsubscribe fro
This patch removes two useless calls of btrfs_header_nritems() in
balance_level().
Signed-off-by: Vincenzo Laurenziello
Signed-off-by: Josef Bacik
---
--- a/fs/btrfs/ctree.c 2012-02-13 20:17:29.0 +0100
+++ b/fs/btrfs/ctree.c 2012-02-16 19:44:59.830817118 +0100
@@ -966,8 +966,6 @@ stat
On Thu, 16 Feb 2012 22:08:11 +0600
Roman Mamedov wrote:
> # mkfs.btrfs /dev/loop7
>
> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
> WARNING! - see http://btrfs.wiki.kernel.org before using
>
> mkfs.btrfs: volumes.c:1575: btrfs_read_chunk_tree: Assertion `!(ret)' failed.
> Aborted
I reran the
On Thu, Feb 16, 2012 at 06:04:47PM +0100, Timo Nentwig wrote:
>
>
> On Wed, 15 Feb 2012, Chris Mason wrote:
>
> >Date: Wed, 15 Feb 2012 08:23:22 -0500
> >From: Chris Mason
> >To: Timo Nentwig
> >Cc: linux-btrfs@vger.kernel.org
> >Subject: Re: can't read superblock (but could mount)
> >
> >On W
Glück Auf!
On kernel 3.2 with btrfs-progs-dangerdonteveruse-62b7993.
I have these subvolumes on a working fs on 1 TB hdd:
ID 257 top level 5 path system-backup-20110803-182701-monthly
ID 481 top level 5 path system-backup-20110901-040001-monthly
ID 809 top level 5 path system-backup-20111001-04000
On Thu, Feb 16, 2012 at 07:55:15PM +0600, Roman Mamedov wrote:
> Hello,
>
> Please be aware that there seems to be a possible problem with using NOCOW
> flag on files situated on a filesystem mounted with compress-force(=lzo, in my
> case).
>
> Since experimenting with NOCOW, I started regularly
On Thu, Feb 16, 2012 at 04:05:40PM +0100, Ahmet Inan wrote:
> On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel 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!
> >>
On Wed, 15 Feb 2012, Chris Mason wrote:
Date: Wed, 15 Feb 2012 08:23:22 -0500
From: Chris Mason
To: Timo Nentwig
Cc: linux-btrfs@vger.kernel.org
Subject: Re: can't read superblock (but could mount)
On Wed, Feb 15, 2012 at 07:03:49AM +0100, Timo Nentwig wrote:
On Tue, 14 Feb 2012, Chris Mas
Hello,
mkfs.btrfs does not seem to work on ARM at the moment.
Linux mahou 3.2.2orion5x-rm1+ #3 Mon Jan 30 19:29:49 YEKT 2012 armv5tel
GNU/Linux
btrfs-tools 0.19+2005-2 from Debian.
# free
total used free sharedbuffers cached
Mem: 60364 49200
Hi,
Ignore this one, it's already in linux-next.
Danny
On Donnerstag, 16. Februar 2012, Danny Kukawka wrote:
> fs/btrfs/check-integrity.c included disk-io.h twice, remove the
> duplicate.
>
> Signed-off-by: Danny Kukawka
> ---
> fs/btrfs/check-integrity.c |1 -
> 1 files changed, 0 inserti
On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel 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
On Thu, Feb 16, 2012 at 07:55:15PM +0600, Roman Mamedov wrote:
> 5813 BUG_ON(!(flags & BTRFS_BLOCK_FLAG_FULL_BACKREF));
>
> I was unable to make netconsole work over a bridged interface, so can only
> post screenshots of this OOPS:
> http://romanrm.ru/pics/2012/2012-02-16-btrfs
fs/btrfs/check-integrity.c included disk-io.h twice, remove the
duplicate.
Signed-off-by: Danny Kukawka
---
fs/btrfs/check-integrity.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index b669a7d..064b29b 100644
--
Hello,
Please be aware that there seems to be a possible problem with using NOCOW
flag on files situated on a filesystem mounted with compress-force(=lzo, in my
case).
Since experimenting with NOCOW, I started regularly hitting this BUG at
extent-tree.c:5813
5813 BUG_ON(!(flag
On Thu, Feb 16, 2012 at 10:06:13AM +0800, Li Zefan wrote:
> Mitch Harder wrote:
> > I've been trying to test the snappy compression patches, but I'm
> > getting corruptions when trying to use snappy as built on my system.
> >
> > I've also tried sourcing my snappy patches from Chris Mason's snappy
You're right about the broken links, my bad.
The first link related to a few statements by Mark Ruijter, copy/pasted below :
> I just looked into it and it appears to be promising.
> On average the speeds appear to be 48% faster then snappy.
> This is amazing since snappy has proved to be 30% f
On Wed, Feb 15, 2012 at 8:06 PM, Li Zefan wrote:
> Mitch Harder wrote:
>> When I copy directory containing a kernel sources git repository to a
>> freshly formated partition mounted with snappy, I get a corrupted
>> copy. If I mount with lzo or lz4 compression, I don't see any
>> corruptions from
clear_state_bit will do merge_state for us, so kick out the redundant one.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index e791fef..039c5c6 100644
--- a/fs/btrfs/extent_i
In clear_extent_bit, it is enough that next node is adjacent in tree level.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index fcf77e1..e941cc4 100644
--- a/fs/btrfs/extent_io
Clearing a range's bits is different with setting them, since we don't
need to touch them when states do not contain bits we want.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrf
When overcommitting, we should check the sum of pinned space and
bytes for delayed item.
Signed-off-by: Liu Bo
---
fs/btrfs/extent-tree.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 283af7a..e4a67c9 100644
---
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
This patch introduce extent buffer cache for every i-node. By this
way, we needn't search the item from the root of b+ tree, and can
save the search time. Besides that we can also reduce the lock contention
of the root.
Implementation:
- add two pointers of extent buffer into btrfs_inode struct, o
On Wed, Jan 18, 2012 at 5:13 PM, Mitch Harder
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
25 matches
Mail list logo
