(2011/05/31 15:13), liubo wrote:
> On 05/31/2011 12:31 PM, Tsutomu Itoh wrote:
>> (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:
# mou
On 05/31/2011 12:31 PM, Tsutomu Itoh wrote:
> (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
(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: no
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
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 used
Smart gcc noticed use of uninitialized warning when compiled
with -O0 flags:
mkfs.c:1291: error: 'file' may be used uninitialized in this function
Signed-off-by: Sergei Trofimovich
---
mkfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mkfs.c b/mkfs.c
index 73c
Signed-off-by: Sergei Trofimovich
---
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)
r
found by valgrind:
==2559== 16 bytes in 1 blocks are definitely lost in loss record 3 of 19
==2559==at 0x4C2720E: malloc (vg_replace_malloc.c:236)
==2559==by 0x412F7E: pretty_sizes (utils.c:1054)
==2559==by 0x4179E9: main (mkfs.c:1395)
Signed-off-by: Sergei Trofimovich
---
mkfs.c |
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==
==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: make_im
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) o
Signed-off-by: Sergei Trofimovich
---
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 inode bitmap and cop
From: Arne Jansen
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 is now sufficient
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 and
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:
$
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
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.
>
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;
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
"b
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)
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 unsubs
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 __alloc_pages_
Excerpts from Andrea Gelmini's message of 2011-05-30 07:59:30 -0400:
> 2011/5/30 Chris Mason :
> > 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 deta
2011/5/29 Chris Mason :
> 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 group 8623489024 has a
2011/5/30 Chris Mason :
> 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 /lib/modules/3.0.0-rc1/k
On Monday 23 May 2011 21:51:57 Josef Bacik wrote:
> On 05/23/2011 07:57 AM, Elric Milon wrote:
> > On Monday 16 May 2011 18:28:49 you wrote:
> >> On 05/16/2011 11:01 AM, Whirm wrote:
> >>> On Monday 16 May 2011 16:11:19 Josef Bacik wrote:
> >>>
> >>>
> >>> Sorry yes, I meant this is how I managed
Excerpts from Andrea Gelmini's message of 2011-05-30 06:13:47 -0400:
> 2011/5/29 Chris Mason :
> > 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:
> defaul
2011/5/29 Chris Mason :
> 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
compress);
b) vanilla kernel
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
---
fs/btrfs/volumes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/volumes.c b
30 matches
Mail list logo
