Cc: Josef
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and mount option of /test5
is as follows:
/dev/sdc3 on /test5 type btrfs
(rw,space_cache,compress=lzo,inode_cache)
So, just a btrfs fi bal would lead to the bug?
I
There was some discussion on where subvolumes live in. Why do we not
simply print the parent ID for each subvolume in btrfs subvolume list.
This patch adds this functionality.
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
btrfs-list.c | 10 --
1 files changed, 8
Add a mutex to btrfs_init_reloc_root() to prevent the reloc tree
creation from concurrent execution.
On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan l...@cn.fujitsu.com wrote:
Cc: Josef
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and
Yan, Zheng wrote:
Add a mutex to btrfs_init_reloc_root() to prevent the reloc tree
creation from concurrent execution.
Thanks!
Unfortunately I can still encounter BUG() in difference places in
each run:
kernel BUG at fs/btrfs/extent-tree.c:6173!
kernel BUG at fs/btrfs/volumes.c:2567!
On
On Sat, Jun 11, 2011 at 05:39:15PM +0200, Andreas Philipp wrote:
On one of my btrfs volumes I see a strange output from filefrag when
run against a particular large (~8GB) file. filefrag and filefrag -v
give me a different number of extents, see below.
aph@thor /mnt/nutshell $ sudo filefrag
Excerpts from Li Zefan's message of 2011-06-13 03:13:13 -0400:
Cc: Josef
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and mount option of /test5
is as follows:
/dev/sdc3 on /test5 type btrfs
On 06/12/2011 09:52 PM, Li Zefan wrote:
Josef Bacik wrote:
We used to store the checksums of the space cache directly in the space
cache,
however that doesn't work out too well if we have more space than we can fit
the
checksums into the first page. So instead use the normal checksumming
We used to store the checksums of the space cache directly in the space cache,
however that doesn't work out too well if we have more space than we can fit the
checksums into the first page. So instead use the normal checksumming
infrastructure. There were problems with doing this originally but
Excerpts from Li Zefan's message of 2011-06-12 22:20:43 -0400:
Chris Mason wrote:
Excerpts from Li Zefan's message of 2011-06-12 21:52:32 -0400:
Josef Bacik wrote:
We used to store the checksums of the space cache directly in the space
cache,
however that doesn't work out too well if
On 06/13/2011 10:11 AM, Chris Mason wrote:
Excerpts from Li Zefan's message of 2011-06-12 22:20:43 -0400:
Chris Mason wrote:
Excerpts from Li Zefan's message of 2011-06-12 21:52:32 -0400:
Josef Bacik wrote:
We used to store the checksums of the space cache directly in the space
cache,
The usage of trans_mutex in relocation code is subtle. It controls
interaction of relocation
with transaction start, transaction commit and snapshot creation.
Simple replacing
trans_mutex with trans_lock is wrong.
On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan l...@cn.fujitsu.com wrote:
Cc: Josef
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
The usage of trans_mutex in relocation code is subtle. It controls
interaction of relocation
with transaction start, transaction commit and snapshot creation.
Simple replacing
trans_mutex with trans_lock is wrong.
What
When allocation fails in btrfs_read_fs_root_no_name, ret is not set
although it is returned, holding a garbage value.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/disk-io.c
Excerpts from Chris Mason's message of 2011-06-13 09:12:06 -0400:
Excerpts from Li Zefan's message of 2011-06-13 03:13:13 -0400:
Cc: Josef
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and mount option of /test5
is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13.06.2011 13:50, David Sterba wrote:
On Sat, Jun 11, 2011 at 05:39:15PM +0200, Andreas Philipp wrote:
On one of my btrfs volumes I see a strange output from filefrag when
run against a particular large (~8GB) file. filefrag and filefrag -v
Hello everybody,
I'm no developer, just a simple user. I use btrfs as the root filesystem
on my laptop. I use VirtualBox. Every VB disk lives in a separat btrfs
subvolume. I use btrfs snapshots for backup and to clone VB VMs.
I wonder what happens when I defrag a file that is part of multiple
On Fri, Jun 10, 2011 at 01:40:31PM +0800, Li Dongyang wrote:
otherwise the patch looks good (and matches my view how to do it). I
will test it eventually.
Thanks a lot, I'll resend this this a proper name.
JFYI, tested in the previous scenario, ie. all devices without trim
support, does not
On Mon, Jun 13, 2011 at 04:50:37PM +0200, Bernhard Duebi wrote:
I'm no developer, just a simple user. I use btrfs as the root filesystem
on my laptop. I use VirtualBox. Every VB disk lives in a separat btrfs
subvolume. I use btrfs snapshots for backup and to clone VB VMs.
I wonder what
Hi Hugo,
I tryed to rebase this patch on your repo, but it seem that it was
already applied. (see commit b3007332100e01ca84c161b6c75f0a414ab4611b)...
Let me know how to proceede
Regards
G.Baroncelli
On 06/12/2011 11:51 PM, Hugo Mills wrote:
Goffredo -
This is missing a S-o-B, and
Hi, Goffredo,
On Mon, Jun 13, 2011 at 06:44:06PM +0200, Goffredo Baroncelli wrote:
I tryed to rebase this patch on your repo, but it seem that it was
already applied. (see commit b3007332100e01ca84c161b6c75f0a414ab4611b)...
Let me know how to proceede
Don't worry, then. I saw the
smatch reported a dead code. It seems to allow wrong item size counting
in leaves, as the first for loop does not adjust the maximum number for
items that would fit in BTRFS_LEAF_DATA_SIZE, and the rest of the code
works with the wrong value. The value of 'nr' is accompanied with
accumulating
smatch reports:
btrfs_recover_log_trees error: 'wc.replay_dest' dereferencing
possible ERR_PTR()
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/tree-log.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index
We used to store the checksums of the space cache directly in the space cache,
however that doesn't work out too well if we have more space than we can fit the
checksums into the first page. So instead use the normal checksumming
infrastructure. There were problems with doing this originally but
Same here, got 5TB in suspense, running btfs-progs-unstable, also tried the
new hugo patches. Kernel 2.6.39-r1 gentoo box
error from mount /dev/sdf1 /server, or btrfsck -s 0,1,2,etc /dev/sdd1:
parent transid verify failed on 2206281838592 wanted 2135 found 1545
btrfsck: disk-io.c:739:
This patch set introduces two new features for scrub. They share the backref
iteration code which is the reason they made it into the same patch set.
The first feature adds printk statements in case scrub finds an error which list
all affected files. You will need patch 1, 2 and 3 for that.
The
These helper functions iterate back references and call a function for each
backref. There is also a function to resolve an inode to a path in the
file system.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/Makefile |3 +-
fs/btrfs/backref.c | 461
While scrubbing, we may encounter various errors. Previously, a logical
address was printed to the log only. Now, all paths belonging to that
address are resolved and printed separately. That should work for hardlinks
as well as reflinks.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
Currently, extent_read_full_page always assumes we are trying to read mirror
0, which generally is the best we can do. To add flexibility, pass it as a
parameter. This will be needed by scrub fixup code.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
fs/btrfs/disk-io.c |2 +-
Fix the mirror_num determination in scrub_stripe. The rest of the scrub code
did not use mirror_num for anything important and that error went unnoticed.
The nodatasum fixup patch of this set depends on a correct mirror_num.
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
In normal operation, scrub is reading data sequentially in large portions.
In case of an i/o error, we try to find the corrupted area(s) by issuing
page sized read requests. With this commit we increment the
unverified_errors counter if all of the small size requests succeed.
Userland patches
This removes a FIXME comment and introduces the first part of nodatasum
fixup: It gets the corresponding inode for a logical address and triggers a
regular readpage for the corrupted sector.
Once we have on-the-fly error correction our error will be automatically
corrected. The correction code is
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
The usage of trans_mutex in relocation code is subtle. It controls
interaction of relocation
with transaction start, transaction commit and snapshot creation.
Simple replacing
trans_mutex with trans_lock is wrong.
So, I've got
Hi,
I've analyzed this error during today and want to share my findings:
On Mon, Jun 13, 2011 at 02:08:21PM -0400, dont wrote:
6. dmesg output:
[ 236.556931] Loglevel set to 9
[ 252.491295] Btrfs loaded
[ 268.978445] device fsid 48487393f515c9b8-be3d620d5899c184 devid 4 transid
906477
On Tue, Jun 14, 2011 at 01:21:00AM +0200, David Sterba wrote:
The code 1972-1979 was added by cleancache. I've asked the reporter to
try it without cleancache, but we did not figure out how to disable it
on commandline (and there was no followup on compiling without
cleancache).
without
On 06/13/2011 05:07 PM, Jim Schutt wrote:
Hi,
On a system under a heavy write load from multiple ceph OSDs,
I'm running into the following hung tasks where btrfs is implicated.
I'm running commit 3c25fa740e2 from Linus' tree merged with
commit cb9b41c92fa from
Andreas Philipp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13.06.2011 13:50, David Sterba wrote:
On Sat, Jun 11, 2011 at 05:39:15PM +0200, Andreas Philipp wrote:
On one of my btrfs volumes I see a strange output from filefrag when
run against a particular large (~8GB) file.
23:18, David Sterba wrote:
When allocation fails in btrfs_read_fs_root_no_name, ret is not set
although it is returned, holding a garbage value.
Signed-off-by: David Sterba dste...@suse.cz
Thanks! My gcc doesn't warn on this..
Reviewed-by: Li Zefan l...@cn.fujitsu.com
--
To unsubscribe
On Tue, Jun 14, 2011 at 3:55 AM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
The usage of trans_mutex in relocation code is subtle. It controls
interaction of relocation
with transaction start, transaction commit and snapshot
Yan, Zheng wrote:
On Tue, Jun 14, 2011 at 3:55 AM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
The usage of trans_mutex in relocation code is subtle. It controls
interaction of relocation
with transaction start, transaction commit
39 matches
Mail list logo
