In degraded mode the struct btrfs_device of missing devs don't have
device-name set. A kstrdup of NULL correctly returns NULL. Don't
BUG in this case.
Signed-off-by: Arne Jansen sensi...@gmx.net
---
fs/btrfs/volumes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
2011/5/29 Chris Mason chris.ma...@oracle.com:
Thanks, could you please send in the photos of the oops when you get
chance.
Well, I retested everything compiling with frame pointers, so:
a) partition is mounted with this flags:
defaults,ssd,noacl,space_cache (at the beginning I also used
Excerpts from Andrea Gelmini's message of 2011-05-30 06:13:47 -0400:
2011/5/29 Chris Mason chris.ma...@oracle.com:
Thanks, could you please send in the photos of the oops when you get
chance.
Well, I retested everything compiling with frame pointers, so:
a) partition is mounted with this
2011/5/30 Chris Mason chris.ma...@oracle.com:
These are perfect, thank you. We're failing to write out the inode
cache. Since you're on a 32 bit machine, I'm guessing that we failed to
kmap something properly.
Thanks a lot for detailed info.
I recompiled, and get this:
gelma@dell:~$ gdb
2011/5/29 Chris Mason chris.ma...@oracle.com:
Thanks, could you please send in the photos of the oops when you get
chance.
By the way, switching from 2.6.38.7 to 2.6.39, I have a lot of this messages:
[ 140.297248] block group 1107296256 has an wrong amount of free space
[ 140.848435] block
Excerpts from Andrea Gelmini's message of 2011-05-30 07:59:30 -0400:
2011/5/30 Chris Mason chris.ma...@oracle.com:
These are perfect, thank you. We're failing to write out the inode
cache. Since you're on a 32 bit machine, I'm guessing that we failed to
kmap something properly.
Thanks
Hi Miao,
When booting 3.0-rc1 with an existing BTRFS filesystem with a normal
desktop use pattern, we see btrfs_batch_insert_item() sometimes
attempt an overly-large kmalloc (= order 11) [1], which is
subsequently failed.
Thanks,
Daniel
--- [1]
WARNING: at mm/page_alloc.c:2074
I have accidently damaged the first block(s) of a btrfs partition
and can't mount it anymore.
I can see that my data is still intact by running a command like:
cat /dev/sda5 | hexdump -C | more
Do any (experimental) tools exist which would allow me to recover the files?
Thank you
--
To
On Mon, May 30, 2011 at 05:59:54PM +0200, Dennis Bergmann wrote:
I have accidently damaged the first block(s) of a btrfs partition
and can't mount it anymore.
I can see that my data is still intact by running a command like:
cat /dev/sda5 | hexdump -C | more
Do any (experimental) tools
On 30.05.2011 18:12, Hugo Mills wrote:
You can check whether it's likely to be of use by running btrfsck
-s 1 on your filesystem. If it passes OK, then btrfs-select-super
should be useful.
Hugo.
Didn't work, unfortunately.
My btrfsck version is v0.19-35-g1b444cd-dirty and running
I got this today, running 2.6.39-07159-gf23a5e1.
The fs in question is mounted:
/dev/sdXX on /usr/local/portage type btrfs (rw,noatime,compress=zlib)
The BUG_ON() call is from:
if (!BTRFS_I(inode)-orphan_meta_reserved) {
BTRFS_I(inode)-orphan_meta_reserved = 1;
Excerpts from Dennis Bergmann's message of 2011-05-30 12:47:01 -0400:
On 30.05.2011 18:12, Hugo Mills wrote:
You can check whether it's likely to be of use by running btrfsck
-s 1 on your filesystem. If it passes OK, then btrfs-select-super
should be useful.
Hugo.
Didn't
Excerpts from Daniel J Blueman's message of 2011-05-30 10:24:08 -0400:
Hi Miao,
When booting 3.0-rc1 with an existing BTRFS filesystem with a normal
desktop use pattern, we see btrfs_batch_insert_item() sometimes
attempt an overly-large kmalloc (= order 11) [1], which is
subsequently
Hugo Mills wrote:
You can check whether it's likely to be of use by running btrfsck
-s 1 on your filesystem. If it passes OK, then btrfs-select-super
should be useful.
Inspired by this I cloned latest btrfs-progs-unstable and tried it on
my broken 60-something GB btrfs, but no luck:
$
Hello friends!
tmp branch recently got very nice feature: 'mkfs.btrfs -r /some/directory'.
It's very useful, when you need to creare minimal root: sh and fs_mark.
But there is another hidden feature! As '-r' can create whole filesystem
we can effectively valgrind a lot of code paths in btrfs
From: Arne Jansen sensi...@gmx.net
When creating a mixed fs with mkfs, an extra metadata chunk got allocated.
This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA,
which in turn wasn't able to find the proper space_info, as __find_space_info
did a hard compare of the flags. It
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
convert.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/convert.c b/convert.c
index fbcf4a3..291dc27 100644
--- a/convert.c
+++ b/convert.c
@@ -1120,7 +1120,7 @@ fail:
return ret;
}
/*
- * scan ext2's
mkfs.btrfs does not handle relative pathnames for now. When
they are passed to it it creates empty image. So first time
I thought it does not work at all.
This patch adds error handling for scandir(). With patch it behaves
this way:
$ mkfs.btrfs -r ./root
...
fs created label (null)
==31873== Command: ./mkfs.btrfs -r /some/root/
==31873== Parent PID: 31872
==31873==
==31873== Conditional jump or move depends on uninitialised value(s)
==31873==at 0x42C3D0: add_file_items (mkfs.c:792)
==31873==by 0x42CAB3: traverse_directory (mkfs.c:948)
==31873==by 0x42CF11:
Found by valgrind:
==8968== Use of uninitialised value of size 8
==8968==at 0x41CE7D: crc32c_le (crc32c.c:98)
==8968==by 0x40A1D0: csum_tree_block_size (disk-io.c:82)
==8968==by 0x40A2D4: csum_tree_block (disk-io.c:105)
==8968==by 0x40A7D6: write_tree_block (disk-io.c:241)
==8968==
Found by valgrind:
==8968== Use of uninitialised value of size 8
==8968==at 0x41CE7D: crc32c_le (crc32c.c:98)
==8968==by 0x40A1D0: csum_tree_block_size (disk-io.c:82)
==8968==by 0x40A2D4: csum_tree_block (disk-io.c:105)
==8968==by 0x40A7D6: write_tree_block (disk-io.c:241)
==8968==
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
mkfs.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/mkfs.c b/mkfs.c
index c8b19c1..73c898b 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -468,6 +468,15 @@ static int directory_select(const struct direct *entry)
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3 /test5
#
# btrfs fi sh /dev/sdc3
Label: none uuid: 38ec48b2-a64b-4225-8cc6-5eb08024dc64
Total devices 5 FS bytes used 7.87MB
devid1 size 10.00GB
Excerpts from Tsutomu Itoh's message of 2011-05-30 20:27:51 -0400:
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3 /test5
#
# btrfs fi sh /dev/sdc3
Label: none uuid: 38ec48b2-a64b-4225-8cc6-5eb08024dc64
(2011/05/31 10:13), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-05-30 20:27:51 -0400:
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3 /test5
#
# btrfs fi sh /dev/sdc3
Label: none uuid:
25 matches
Mail list logo
