Not important at all since exit() is called afterwards and this is
not part of the library. It just makes valgrind happy and thus
allows to search for real flaws.
Signed-off-by: Stefan Behrens
---
cmds-send.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
For the objectid and offset field of a key, print -1 instead of the
decimal representation of 0x. At least for me it is
more readable like this.
Signed-off-by: Stefan Behrens
---
print-tree.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/print-tree.c
Several tools like btrfs-send and btrfs-receive need to map a
subvolume ID to a filesystem path. The so far existing methods
in btrfs-list.c cause a horrible effort when performing this
operation (and the effort is dependent on the number of
existing subvolumes with quadratic effort). This commit a
When qgroup tracking is enabled, we do an automatic cycle of the new rescan
mechanism.
Signed-off-by: Jan Schmidt
---
fs/btrfs/qgroup.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 249dd64..b1ae0ab 100644
--- a/fs/
The function is separated into a preparation part and the three accounting
steps mentioned in the qgroups documentation. The goal is to make steps two
and three usable by the rescan functionality. A side effect is that the
function is restructured into readable subunits.
Signed-off-by: Jan Schmidt
The kernel side for rescan, which is needed if you want to enable qgroup
tracking on a non-empty volume. The first patch splits
btrfs_qgroup_account_ref into readable ans reusable units. The second
patch adds the rescan implementation (refer to its commit message for a
description of the algorithm)
If qgroup tracking is out of sync, a rescan operation can be started. It
iterates the complete extent tree and recalculates all qgroup tracking data.
This is an expensive operation and should not be used unless required.
A filesystem under rescan can still be umounted. The rescan continues on the
Hello Jan,
> If qgroup tracking is out of sync, a rescan operation can be started. It
> iterates the complete extent tree and recalculates all qgroup tracking data.
> This is an expensive operation and should not be used unless required.
>
> A filesystem under rescan can still be umounted. The re
Hello Jan,
[..snip..]
> /*
>* the delayed ref sequence number we pass depends on the direction of
>* the operation. for add operations, we pass (node->seq - 1) to skip
> @@ -1401,7 +1428,17 @@ int btrfs_qgroup_account_ref(struct btrfs_trans_handle
> *trans,
> if (re
On Tue, April 23, 2013 at 14:05 (+0200), Wang Shilong wrote:
> Hello Jan,
>
> [..snip..]
>
>
>
>> /*
>> * the delayed ref sequence number we pass depends on the direction of
>> * the operation. for add operations, we pass (node->seq - 1) to skip
>> @@ -1401,7 +1428,17 @@ int bt
This commit changes the btrfs send/receive commands to use the
UUID tree to map UUIDs to subvolumes, and to use the root tree
to map subvolume IDs to paths. Now these tools start fast and are
independent on the number of subvolumes/snapshots that exist.
Before this commit, mapping UUIDs to subvolu
This commit adds uuid-tree lookup methods that make use of the search
ioctl. The code is based on the kernel code.
Signed-off-by: Stefan Behrens
---
Makefile| 2 +-
ctree.h | 5 ++
uuid-tree.c | 196
3 files changed, 202 in
This commit changes the btrfs send/receive commands to use the
UUID tree to map UUIDs to subvolumes, and to use the root tree
to map subvolume IDs to paths. Now these tools start fast and are
independent on the number of subvolules/snapshot that exist.
Before this commit, mapping UUIDs to subvolum
Support printing these things.
Signed-off-by: Stefan Behrens
---
ctree.h | 29 +++
print-tree.c | 91 ++--
2 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/ctree.h b/ctree.h
index 4ea37ac..f25e2df 100644
I need to know soon if there is going to be anything I can do to
rescue this filesystem.
I've tried 3.7.10, 3.8.[5,6,7,8] and btrfs-next as of (
bba653d1207646b17671c6cb9a0629736811848a ).
btrfs-next - at least - merely failed the mount, all of the others
failed but also ran into a BUG, requiring a
A user sent me a btrfs-image that was panicing because of some corruption. This
is because we pass in a bogus value to btrfs_num_copies, and it panics. Instead
just return 1. We only call btrfs_num_copies to see if there are other copies
to try and read for things, so if we just return 1 it will
Hello Jan,
>
> +static void btrfs_qgroup_rescan_worker(struct btrfs_work *work)
> +{
> + struct qgroup_rescan *qscan = container_of(work, struct qgroup_rescan,
> +work);
> + struct btrfs_path *path;
> + struct btrfs_trans_handle *trans
On Tue, Apr 23, 2013 at 09:20:45AM -0500, Jon Nelson wrote:
> I need to know soon if there is going to be anything I can do to
> rescue this filesystem.
> I've tried 3.7.10, 3.8.[5,6,7,8] and btrfs-next as of (
> bba653d1207646b17671c6cb9a0629736811848a ).
> btrfs-next - at least - merely failed th
This work is done by btrfs_free_path() anyway so there's no need for this
duplicate work. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/tree-log.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 52287ec..1fdc221 10
With a users corrupted fs I was getting weird behavior and panics and it turns
out it was because one of his tree blocks had a bogus header level. So add this
to the sanity checks in the endio handler for tree blocks. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/disk-io.c |6 ++
1 f
On Tue, Apr 23, 2013 at 01:26:51PM +0200, Jan Schmidt wrote:
> --- a/fs/btrfs/qgroup.c
> +++ b/fs/btrfs/qgroup.c
> @@ -1494,10 +1494,14 @@ int btrfs_run_qgroups(struct btrfs_trans_handle
> *trans,
> {
> struct btrfs_root *quota_root = fs_info->quota_root;
> int ret = 0;
> + int st
On Tue, Apr 23, 2013 at 05:36:23PM +0200, David Sterba wrote:
> The original question I've had is what sort of work does rescan do
> because it's on the commit path and we don't want to add more work and
> delay commit.
It just wakes up the rescan worker, not a problem.
--
To unsubscribe from this
On Sun, Apr 21, 2013 at 05:10:44PM -0500, Eric Sandeen wrote:
> 2 patches here.
I see only
[PATCH 2/2] btrfs-progs: Add default rules to Makefile
in my mbox that's threaded under the 0/2 cover mail.
> I think this is a net win, with a bit less Makefile code
> duplication, but if people don't li
On Tue, Apr 23, 2013 at 10:03 AM, Liu Bo wrote:
>
> Can you please show us where it BUG_ON(or logs) when mounting with "-o
> recovery"?
> (the stack info below seems not to be a resulf of '-o recovery'?)
I have this from 3.8.8:
2013-04-19T21:19:47.060937-05:00 turnip kernel: [ 100.608815] devi
On Mon, Apr 22, 2013 at 12:16:41AM -0500, Eric Sandeen wrote:
> This addresses the same issue as did:
>
> 2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck
>
> but rather than optionally updating generation_v2 based
> on the size of the existing item, increase the size of
On Apr 23, 2013, at 11:09 AM, David Sterba wrote:
> On Sun, Apr 21, 2013 at 05:10:44PM -0500, Eric Sandeen wrote:
>> 2 patches here.
>
> I see only
>
> [PATCH 2/2] btrfs-progs: Add default rules to Makefile
>
> in my mbox that's threaded under the 0/2 cover mail.
>
I must have run into a size
If we fail to load block groups halfway through we can leave extent_state's on
the excluded tree. This is because we just lookup the supers and add them to
the excluded tree regardless of which block group we are looking at currently.
This is a problem because we remove the excluded extents for th
On Mon, Apr 22, 2013 at 11:12:31AM -0500, Eric Sandeen wrote:
> Clean up the leak debugging in extent_io.c by moving
> the debug code into functions. This also removes the
> list_heads used for debugging from the extent_buffer
> and extent_state structures when debug is not enabled.
>
> Since we
On Tue, Apr 23, 2013 at 12:18:55PM +0200, Stefan Behrens wrote:
> Several tools like btrfs-send and btrfs-receive need to map a
> subvolume ID to a filesystem path. The so far existing methods
> in btrfs-list.c cause a horrible effort when performing this
> operation (and the effort is dependent on
On Tue, April 23, 2013 at 17:36 (+0200), David Sterba wrote:
> On Tue, Apr 23, 2013 at 01:26:51PM +0200, Jan Schmidt wrote:
>> --- a/fs/btrfs/qgroup.c
>> +++ b/fs/btrfs/qgroup.c
>> @@ -1494,10 +1494,14 @@ int btrfs_run_qgroups(struct btrfs_trans_handle
>> *trans,
>> {
>> struct btrfs_root *q
On Tue, April 23, 2013 at 16:54 (+0200), Wang Shilong wrote:
>
> Hello Jan,
>
>>
>> +static void btrfs_qgroup_rescan_worker(struct btrfs_work *work)
>> +{
>> +struct qgroup_rescan *qscan = container_of(work, struct qgroup_rescan,
>> + work);
>>
Sequence numbers for delayed refs have been introduced in the first version
of the qgroup patch set. To solve the problem of find_all_roots on a busy
file system, the tree mod log was introduced. The sequence numbers for that
were simply shared between those two users.
However, at one point in qgr
We kept leaking extent buffers when mounting a broken file system and it turns
out it's because not everybody uses read_tree_block properly. You need to check
and make sure the extent_buffer is uptodate before you use it. This patch fixes
everybody who calls read_tree_block directly to make sure
If we fail to load block groups halfway through we can leave extent_state's on
the excluded tree. This is because we just lookup the supers and add them to
the excluded tree regardless of which block group we are looking at currently.
This is a problem because we remove the excluded extents for th
On Wed, Apr 03, 2013 at 03:14:56AM -0600, Miao Xie wrote:
> Using the structure btrfs_sector_sum to keep the checksum value is
> unnecessary, because the extents that btrfs_sector_sum points to are
> continuous, we can find out the expected checksums by btrfs_ordered_sum's
> bytenr and the offset,
For any btrfs-$FOO executable, rename the main source file from
$FOO.c to to btrfs-$FOO.c
This makes it slightly more obvious what's building what,
and allows us to write a default rule in the Makefile for
these tools.
(also add btrfs-calc-size to the list of objects to remove
on make clean)
Sig
36 matches
Mail list logo
