On 8/27/19 9:56 AM, Qu Wenruo wrote:
>
>
> On 2019/8/27 下午9:37, Jeff Mahoney wrote:
>> On 8/27/19 9:22 AM, Qu Wenruo wrote:
>>> Btrfs doesn't reuse devid, thus if we add and delete device in a loop,
>>> we can increase devid to higher value, triggering
n increase to any
> + * value, but we don't believe a devid higher than (1<<32) is really
> + * valid. This could at least detect bitflip at the higher
> + * 32 bits while still consider high devid valid.
> + */
> + u64 max_devid = (1ULL <&
> On Aug 13, 2019, at 9:54 PM, Qu Wenruo wrote:
>
>
>
>> On 2019/8/14 上午9:04, Jeff Mahoney wrote:
>> Printing the error number means having to go look up what that error
>> number means. For a developer, it's easy. For a user, it's unhel
The only difference between parse_limit and parse_size is that
parse_limit accepts "none" as a valid input. That's easy enough
to handle as a special case and lets us drop the duplicate code.
Signed-off-by: Jeff Mahoney
---
cmd
When btrfs_add_to_fsid fails in mkfs we try to close the ctree. That
complains that we already have a transaction open. We should be taking
the error path and exit cleanly without writing.
Signed-off-by: Jeff Mahoney
---
mkfs/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
r message. We also do overflow/underflow
checking when -/+ size is used and report those errors as well.
Signed-off-by: Jeff Mahoney
---
cmds/filesystem.c | 41 +
common/utils.c| 2 +-
common/utils.h| 2 +-
3 files changed, 43 insertions(+),
need to check for overflow and reject the device if it would overflow.
I've copied include/linux/overflow.h from the kernel to reuse that code.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1099147
Signed-off-by: Jeff Mahoney
---
common/device-scan.c | 15 +-
Printing the error number means having to go look up what that error
number means. For a developer, it's easy. For a user, it's unhelpful.
Signed-off-by: Jeff Mahoney
---
mkfs/main.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletion
>>> loop in commit in progs.
>>
>> Shouldn't the new patch version be sent to the list for review?
>> It doesn't seem to be a trivial change on first through.
>
> Ok, I've removed the patches from devel and will send them once the
> release is done.
>
Hi Dave -
Did this ever get revisited?
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
rence to verify it. There are
two potential solutions to this:
1) Change the tree nodes to contain checksums for each of the next blocks.
2) Use an hmac in each tree node and leaf, where the signature functions
as the external reference.
Either solution requires checksums be added to the sup
I'd be more than happy if
>> I
>> could just use an enum.
>
> Enum is fine, but named constants that are part of on-disk format should
> be spell the exact value, ie. not relying on the auto-increment of enum
> values.
>
FWIW, enum values make it into the debuginf
;s
not written to the image file anyway. I do want a btrfs-image file from
the file system, and if btrfs-image fails to create a usable image,
that's also valuable to know and fix.
Thanks,
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 4/2/19 3:19 PM, Filipe Manana wrote:
> On Tue, Apr 2, 2019 at 7:29 PM wrote:
>>
>> From: Jeff Mahoney
>>
>> When repairing the extent tree, it's possible for delayed extents to
>> be created when running btrfs_write_dirty_block_groups. We run
>>
few things.
Comments?
It sounds like you're coming from a Solaris environment with ZFS and are
expecting Btrfs on Linux to be a drop-in replacement, and neither are.
There are certainly ideas we can borrow from ZFS, though.
-Jeff
--
Jeff Mahoney
SUSE Labs
except btrfs metadata nodes, which are 16k.
So, I don't think changing the file system block size is the right
approach. It *may* bring benefits, but I think many of the same
benefits can be gained by using the minimum-size option for fstrim and
allowing the discard mount options to accept a minimum size as well.
-Jeff
--
Jeff Mahoney
SUSE Labs
rt += len;
>>> *trimmed += bytes;
>>>
>>> + /* We've trimmed enough */
>>> + if (*trimmed >= range->len)
>>> + break;
>>> +
>>> if (fatal_signal_pending(current)) {
>>> ret = -ERESTARTSYS;
>>> break;
>>> @@ -11341,8 +11355,7 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info,
>>> struct fstrim_range *range)
>>> mutex_lock(&fs_info->fs_devices->device_list_mutex);
>>> devices = &fs_info->fs_devices->devices;
>>> list_for_each_entry(device, devices, dev_list) {
>>> - ret = btrfs_trim_free_extents(device, range->minlen,
>>> - &group_trimmed);
>>> + ret = btrfs_trim_free_extents(device, range, &group_trimmed);
>>> if (ret) {
>>> dev_failed++;
>>> dev_ret = ret;
>>> --
>>> 2.17.1
>
--
Jeff Mahoney
SUSE Labs
On 1/8/19 4:02 PM, Giuseppe Della Bianca wrote:
> In data lunedì 7 gennaio 2019 23:40:19 CET, Jeff Mahoney ha scritto:
> ]zac[
>>> If you want, I can send you the full log (very long).
>>> From what you wrote below it seems to me that you do not need it
>>
>>
On 1/5/19 7:30 AM, Giuseppe Della Bianca wrote:
> In data venerdì 4 gennaio 2019 21:34:03 CET, Jeff Mahoney ha scritto:
> ]zac[
>>>
>>> root 17133 17127 0 17:17 ?00:00:00 btrfs subvolume sync -s 2
>>> /
>>> tmp/tmp.p9SiQ1GnpV
>>>
&g
On 1/1/19 11:37 AM, Giuseppe Della Bianca wrote:
> In data giovedì 9 agosto 2018 20:48:03 CEST, Jeff Mahoney ha scritto:
>> On 8/9/18 11:15 AM, Giuseppe Della Bianca wrote:
>>> Hi.
>>>
>>> My system:
>>> - Fedora 28 x86_64
>>> - kernel-4.1
@ int btrfs_qgroup_account_extents(struct
> btrfs_trans_handle *trans)
> trace_btrfs_qgroup_account_extents(fs_info, record);
>
> if (!ret) {
> - /*
> - * Old roots should be searched when inserting qgroup
> - * extent record
> - */
> - if (WARN_ON(!record->old_roots)) {
> + if (!record->old_roots) {
> /* Search commit root to find old_roots */
> ret = btrfs_find_all_roots(NULL, fs_info,
> record->bytenr, 0,
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
s_qgroup_trace_leaf_items(struct btrfs_trans_handle *trans,
> @@ -2557,11 +2530,7 @@ int btrfs_qgroup_account_extents(struct
> btrfs_trans_handle *trans)
> trace_btrfs_qgroup_account_extents(fs_info, record);
>
> if (!ret) {
> - /*
> - * Old roots should be searched when inserting qgroup
> - * extent record
> - */
> - if (WARN_ON(!record->old_roots)) {
> + if (!record->old_roots) {
> /* Search commit root to find old_roots */
> ret = btrfs_find_all_roots(NULL, fs_info,
> record->bytenr, 0,
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
fs/btrfs/file.c | 29
fs/btrfs/inode.c| 54 +
fs/btrfs/ioctl.c|5
fs/btrfs/super.c| 15 ++
fs/dax.c| 35 --
include/linux/dax.h | 16 ++
9 files changed, 430 insertions(+), 45 deletions(-)
--
Jeff Mahoney
SUSE Labs
that do this already) and not pay any performance penalty. The idea
with DAX mmap is that the file system manages the namespace, space
allocation, and permissions. Otherwise we stay out of the way.
-Jeff
--
Jeff Mahoney
SUSE Labs
On 9/7/18 8:00 AM, David Sterba wrote:
> On Thu, Sep 06, 2018 at 04:59:33PM -0400, je...@suse.com wrote:
>> From: Jeff Mahoney
>
> If this is a resend, I can't find the previous postings, same or similar
> subject.
I had tagged it as submitted in March, but I can't f
nc -s 2 xyz' .
> - After some time the kernel reports an error on the filesystem.
> (error that existed before the command was launched.)
> - The filesystem goes in read-only mode.
> - The command hangs.
Can you provide the output of 'dmesg' and the contents of
/proc//stack
rfs loaded, crc32c=%s", crc32c_impl());
#ifdef CONFIG_BTRFS_DEBUG
- ", debug=on"
+ pr_cont(", debug=on");
#endif
#ifdef CONFIG_BTRFS_ASSERT
- ", assert=on"
+ pr_cont(", assert=on");
#endif
#ifdef CONFIG
dize on taking only a trans handle when one is required and both
a trans and fs_info when it's optional, it'll make the code clearer.
This cleanup can percolate up the stack to cover pretty much all of
delayed refs.
Reviewed-by: Jeff Mahoney
> Signed-off-by: Nikolay Borisov
> ---
xtents this parameter holds the level in the
> + * tree of the parent block.
>
As mentioned above, it holds the level of the tree that contains the
block. The parent can be looked up indirectly by taking this level and
adding 1 until we hit the level of the root node.
> + * @o
gt; err = write_page_nocow(nocow_ctx->sctx,
> physical_for_dev_replace, page);
> @@ -4651,6 +4678,19 @@ static int copy_nocow_pages_for_inode(u64 inum, u64
> offset, u64 root,
> inode_unlock(inode);
> iput(inode);
> return ret;
> +
> +fallback:
> + inode_unlock(inode);
> + iput(inode);
> +
> + ret = scrub_pages(nocow_ctx->sctx, nocow_ctx->logical,
> + nocow_ctx->len, nocow_ctx->fb_physical,
> + nocow_ctx->fb_dev, BTRFS_EXTENT_FLAG_DATA,
> + nocow_ctx->fb_gen, nocow_ctx->mirror_num,
> + NULL, 0, physical_for_dev_replace);
> + if (!ret)
> + ret = COPY_COMPLETE;
> + return ret;
> }
>
> static int write_page_nocow(struct scrub_ctx *sctx,
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
nterface.
btrfs_listxattr could get interesting, though I suppose we could
simplify it by only allowing the per-subvolume and fs-global operations
on root inodes.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
tl on each mount? Properties could work, but
there's more discussion needed there. Personally, I like the property
idea since it could conceivably be used on a per-file basis.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
trfs_work *work)
> path = btrfs_alloc_path();
> if (!path)
> goto out;
> + /*
> + * Rescan should only search for commit root, and any later difference
> + * should be recorded by qgroup
> + */
> + path->search_commit_root = 1;
>
> err = 0;
> while (!err && !btrfs_fs_closing(fs_info)) {
>
If we're searching the commit root here, do we need the tree mod
sequence number dance in qgroup_rescan_leaf anymore?
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
it the transaction if everything went well.
> + * To make the live accounting work in this phase, we set our
> + * scan progress pointer such that every real extent objectid
> + * will be smaller.
> + */
> + fs_info->qgroup_rescan_progress.objectid = (u64)-1;
> + btrfs_release_path(path);
> + mutex_unlock(&fs_info->qgroup_rescan_lock);
> + return 1;
> }
>
> static void btrfs_qgroup_rescan_worker(struct btrfs_work *work)
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 4/17/18 2:45 PM, Jeff Mahoney wrote:
> On a file system with many snapshots and qgroups enabled, an interrupted
> balance can end up taking a long time to mount due to recovering the
> relocations during mount. It does this in the task performing the mount,
> which can't be in
On 5/2/18 5:11 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
> ended up reintroducing the hang-on-unmount bug that the commit it
> intende
On 5/2/18 5:11 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
> ended up reintroducing the hang-on-unmount bug that the commit it
> intende
since the
underlying file system would still be active underneath it. Under the
hood, things like relocation don't even look at what subvolume owns a
particular extent until it must. So it could be coordinating thousands
of superblocks to do what a single lock does now and for what benefit?
>> It's far more efficient then to pull those fields we need for a
>> subvolume namespace into their own structure.
>
> I'm not convinced yet - it still feels like it's the wrong layer to
> be solving the multiple namespace per superblock problem
It needs to be between the inode and the superblock. If there are
multiple user-visible namespaces, each will still get the same
underlying file system namespace.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 5/4/18 1:59 AM, Nikolay Borisov wrote:
>
>
> On 4.05.2018 01:27, Jeff Mahoney wrote:
>> On 5/3/18 2:23 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.05.2018 00:11, je...@suse.com wrote:
>>>> From: Jeff Mahoney
>>>>
>>
On 5/3/18 2:23 AM, Nikolay Borisov wrote:
>
>
> On 3.05.2018 00:11, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Hi Dave -
>>
>> Here's the updated patchset for the rescan races. This fixes the issue
>> where we'd try to start mult
On 5/3/18 11:52 AM, Nikolay Borisov wrote:
>
>
> On 3.05.2018 16:39, Jeff Mahoney wrote:
>> On 5/3/18 3:24 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.05.2018 00:11, je...@suse.com wrote:
>>>> From: Jeff Mahoney
>>>>
>&
On 5/3/18 3:24 AM, Nikolay Borisov wrote:
>
>
> On 3.05.2018 00:11, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Commit 8d9eddad194 (Btrfs: fix qgroup rescan worker initialization)
>> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
>
On 5/2/18 9:15 AM, David Sterba wrote:
> On Wed, May 02, 2018 at 12:29:28PM +0200, David Sterba wrote:
>> On Thu, Apr 26, 2018 at 03:23:49PM -0400, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>> +static void queue_rescan_worker(struct btrfs_fs_info *fs_info)
>>
oth.
>
> Thanks,
> Vijay
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jeff Mahoney
SUSE Labs
--
To unsu
On 4/30/18 2:20 AM, Qu Wenruo wrote:
>
>
> On 2018年04月27日 03:23, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization)
>> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
>
On 4/29/18 6:13 AM, David Sterba wrote:
> On Fri, Apr 27, 2018 at 03:18:17PM -0400, Jeff Mahoney wrote:
>> On 4/27/18 2:56 PM, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking)
>>>
On 4/27/18 12:40 PM, David Sterba wrote:
> On Fri, Apr 27, 2018 at 12:02:13PM -0400, Jeff Mahoney wrote:
>>>> +static void queue_rescan_worker(struct btrfs_fs_info *fs_info)
>>>> +{
>>>
>>> And this had to be moved upwards as there was earlier use of
&g
On 4/27/18 2:56 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking)
> started m4_chomp to strip the newlines from the version file. m4_chomp
> was introduced in autoconf 2.64 but SLE11 ships with autoconf 2.63.
&g
If we fail to allocate memory for a path, don't bother trying to
insert the qgroup status item. We haven't done anything yet and it'll
fail also. Just print an error and be done with it.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/qgroup.c | 9 -
1 file changed, 4 i
On 4/27/18 11:44 AM, David Sterba wrote:
> On Thu, Apr 26, 2018 at 11:39:50PM +0300, Nikolay Borisov wrote:
>> On 26.04.2018 22:23, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> If we fail to allocate memory for a path, don't bother trying to
>&
On 4/27/18 11:56 AM, David Sterba wrote:
> On Thu, Apr 26, 2018 at 03:23:49PM -0400, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization)
>> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, bu
On 4/27/18 4:48 AM, Filipe Manana wrote:
> On Thu, Apr 26, 2018 at 8:23 PM, wrote:
>> From: Jeff Mahoney
>>
>> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization)
>> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
>> ended up
On 4/23/18 5:43 PM, David Sterba wrote:
> On Tue, Apr 17, 2018 at 02:45:33PM -0400, Jeff Mahoney wrote:
>> On a file system with many snapshots and qgroups enabled, an interrupted
>> balance can end up taking a long time to mount due to recovering the
>> relocations during mo
allow any new balance operations if it's running, and
wait for it on umount and remounting read-only.
This doesn't do anything to address the relocation recovery operation
taking a long time but does allow the file system to mount.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/ctree.h
{
>>> ret = PTR_ERR(eb);
>>> break;
>>> @@ -2036,6 +2040,8 @@ int walk_down_reloc_tree(struct btrfs_root *root,
>>> struct btrfs_path *path,
>>> last_snapshot = btrfs_root_last_snapshot(&root->root_item);
>>>
>>> for (i = *level; i > 0; i--) {
>>> + struct btrfs_key first_key;
>>> +
>>> eb = path->nodes[i];
>>> nritems = btrfs_header_nritems(eb);
>>> while (path->slots[i] < nritems) {
>>> @@ -2056,7 +2062,9 @@ int walk_down_reloc_tree(struct btrfs_root *root,
>>> struct btrfs_path *path,
>>> }
>>>
>>> bytenr = btrfs_node_blockptr(eb, path->slots[i]);
>>> - eb = read_tree_block(fs_info, bytenr, ptr_gen);
>>> + btrfs_node_key_to_cpu(eb, &first_key, path->slots[i]);
>>> + eb = read_tree_block(fs_info, bytenr, ptr_gen, &first_key,
>>> +i - 1);
>>> if (IS_ERR(eb)) {
>>> return PTR_ERR(eb);
>>> } else if (!extent_buffer_uptodate(eb)) {
>>> @@ -2714,6 +2722,8 @@ static int do_relocation(struct btrfs_trans_handle
>>> *trans,
>>> path->lowest_level = node->level + 1;
>>> rc->backref_cache.path[node->level] = node;
>>> list_for_each_entry(edge, &node->upper, list[LOWER]) {
>>> + struct btrfs_key first_key;
>>> +
>>> cond_resched();
>>>
>>> upper = edge->node[UPPER];
>>> @@ -2779,7 +2789,9 @@ static int do_relocation(struct btrfs_trans_handle
>>> *trans,
>>>
>>> blocksize = root->fs_info->nodesize;
>>> generation = btrfs_node_ptr_generation(upper->eb, slot);
>>> - eb = read_tree_block(fs_info, bytenr, generation);
>>> + btrfs_node_key_to_cpu(upper->eb, &first_key, slot);
>>> + eb = read_tree_block(fs_info, bytenr, generation, &first_key,
>>> +upper->level - 1);
>>> if (IS_ERR(eb)) {
>>> err = PTR_ERR(eb);
>>> goto next;
>>> @@ -2944,7 +2956,8 @@ static int get_tree_block_key(struct btrfs_fs_info
>>> *fs_info,
>>> struct extent_buffer *eb;
>>>
>>> BUG_ON(block->key_ready);
>>> - eb = read_tree_block(fs_info, block->bytenr, block->key.offset);
>>> + eb = read_tree_block(fs_info, block->bytenr, block->key.offset, NULL,
>>> +0);
>>> if (IS_ERR(eb)) {
>>> return PTR_ERR(eb);
>>> } else if (!extent_buffer_uptodate(eb)) {
>>> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
>>> index 434457794c27..b98a1801b406 100644
>>> --- a/fs/btrfs/tree-log.c
>>> +++ b/fs/btrfs/tree-log.c
>>> @@ -304,7 +304,7 @@ static int process_one_buffer(struct btrfs_root *log,
>>> * pin down any logged extents, so we have to read the block.
>>> */
>>> if (btrfs_fs_incompat(fs_info, MIXED_GROUPS)) {
>>> - ret = btrfs_read_buffer(eb, gen);
>>> + ret = btrfs_read_buffer(eb, gen, NULL, 0);
>>> if (ret)
>>> return ret;
>>> }
>>> @@ -2420,7 +2420,7 @@ static int replay_one_buffer(struct btrfs_root *log,
>>> struct extent_buffer *eb,
>>> int i;
>>> int ret;
>>>
>>> - ret = btrfs_read_buffer(eb, gen);
>>> + ret = btrfs_read_buffer(eb, gen, NULL, 0);
>>> if (ret)
>>> return ret;
>>>
>>> @@ -2537,6 +2537,8 @@ static noinline int walk_down_log_tree(struct
>>> btrfs_trans_handle *trans,
>>> WARN_ON(*level >= BTRFS_MAX_LEVEL);
>>>
>>> while (*level > 0) {
>>> + struct btrfs_key first_key;
>>> +
>>> WARN_ON(*level < 0);
>>> WARN_ON(*level >= BTRFS_MAX_LEVEL);
>>> cur = path->nodes[*level];
>>> @@ -2549,6 +2551,7 @@ static noinline int walk_down_log_tree(struct
>>> btrfs_trans_handle *trans,
>>>
>>> bytenr = btrfs_node_blockptr(cur, path->slots[*level]);
>>> ptr_gen = btrfs_node_ptr_generation(cur, path->slots[*level]);
>>> + btrfs_node_key_to_cpu(cur, &first_key, path->slots[*level]);
>>> blocksize = fs_info->nodesize;
>>>
>>> parent = path->nodes[*level];
>>> @@ -2567,7 +2570,8 @@ static noinline int walk_down_log_tree(struct
>>> btrfs_trans_handle *trans,
>>>
>>> path->slots[*level]++;
>>> if (wc->free) {
>>> - ret = btrfs_read_buffer(next, ptr_gen);
>>> + ret = btrfs_read_buffer(next, ptr_gen,
>>> + &first_key, *level - 1);
>>> if (ret) {
>>> free_extent_buffer(next);
>>> return ret;
>>> @@ -2597,7 +2601,7 @@ static noinline int walk_down_log_tree(struct
>>> btrfs_trans_handle *trans,
>>> free_extent_buffer(next);
>>> continue;
>>> }
>>> - ret = btrfs_read_buffer(next, ptr_gen);
>>> + ret = btrfs_read_buffer(next, ptr_gen, &first_key, *level - 1);
>>> if (ret) {
>>> free_extent_buffer(next);
>>> return ret;
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 3/19/18 2:08 PM, David Sterba wrote:
> On Mon, Mar 19, 2018 at 01:52:05PM -0400, Jeff Mahoney wrote:
>> On 3/16/18 4:12 PM, David Sterba wrote:
>>> On Fri, Mar 16, 2018 at 02:36:27PM -0400, je...@suse.com wrote:
>>>> From: Jeff Mahoney
>>>>
>>
On 3/16/18 4:12 PM, David Sterba wrote:
> On Fri, Mar 16, 2018 at 02:36:27PM -0400, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> While running btrfs/011, I hit the following lockdep splat.
>>
>> This is the important bit:
>>pcpu_alloc+0x1ac/0x5e
On 3/16/18 4:12 PM, David Sterba wrote:
> On Fri, Mar 16, 2018 at 02:36:27PM -0400, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> While running btrfs/011, I hit the following lockdep splat.
>>
>> This is the important bit:
>>pcpu_alloc+0x1ac/0x5e
On 3/16/18 2:48 PM, Nikolay Borisov wrote:
>
>
> On 16.03.2018 20:36, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> While running btrfs/011, I hit the following lockdep splat.
>>
>> This is the important bit:
>>pcpu_alloc+0x1a
tatic DEFINE_SIMPLE_COMMAND(filesystem_defrag, "defrag");
"defragment"
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 3/7/18 9:40 PM, je...@suse.com wrote:
> From: Jeff Mahoney
> diff --git a/cmds-inspect.c b/cmds-inspect.c
> index afd7fe48..12f200b3 100644
> --- a/cmds-inspect.c
> +++ b/cmds-inspect.c
> @@ -625,33 +629,27 @@ static int cmd_inspect_min_dev_size(int argc, char
> **argv)
&
On 3/8/18 12:54 AM, Qu Wenruo wrote:
>
>
> On 2018年03月08日 10:40, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> The only mechanism we have in the progs for searching qgroups is to load
>> all of them and filter the results. This works for qgroup show b
On 3/8/18 12:33 AM, Qu Wenruo wrote:
>
>
> On 2018年03月08日 10:40, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> The btrfs qgroup show command currently only exports qgroup IDs,
>> forcing the user to resolve which subvolume each corresponds to.
>>
&g
On 3/7/18 3:17 AM, Nikolay Borisov wrote:
>
>
> On 2.03.2018 20:46, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> It's unlikely we're going to modify a pathname argument, so codify that
>> and use const.
>>
>> Signed-off-by: Jef
On 3/7/18 3:02 AM, Misono, Tomohiro wrote:
> On 2018/03/03 3:47, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> The only mechanism we have in the progs for searching qgroups is to load
>> all of them and filter the results. This works for qgroup show but
>> t
On 3/7/18 1:09 AM, Qu Wenruo wrote:
>
>
> On 2018年03月03日 02:47, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> This patch reports on the first-level qgroup, if any, associated with
>> a particular subvolume. It displays the usage and limit, subjec
comparison in the ioctl
only does a regular key comparison and offset doesn't get evaluated if
the types aren't equal. That works fine when doing tree insertion or
searches for a single key but is wrong for searching for a range. I
have a TREE_SEARCH_V3 lying around somewhere to address this ridiculous
behavior and should probably finish it up at some point.
This hasn't mattered for __qgroup_search until now since it hasn't used
anything other than -1 for the offset and objectid so I'll just add a
filter there.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
oup into qgroup_lookup.
>> *
>> @@ -588,7 +697,7 @@ static struct btrfs_qgroup *qgroup_tree_search(struct
>> qgroup_lookup *root_tree,
>> * Return the pointer to the btrfs_qgroup if found or if inserted
>> successfully.
>> * Return ERR_PTR if any error occurred.
&
ry qgroup to
resolve a constant. I'll replace the magic number with a define though.
> BTW, the result is just 22.
It's a worst-case. We're using %llu, so 42 is the length of two 64-bit
numbers in base ten, plus the slash and nul terminator. In practice we
won't hit the limit, but it doesn't hurt.
Thanks for the review.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 3/2/18 1:59 PM, Nikolay Borisov wrote:
>
>
> On 2.03.2018 20:46, je...@suse.com wrote:
>> From: Jeff Mahoney
>> @@ -135,8 +141,9 @@ static int cmd_quota_rescan(int argc, char **argv)
>> }
>> }
>>
>> -if (ioctlnum !=
On 3/2/18 1:39 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Hi all -
>
> The following series addresses some usability issues with the qgroups UI.
>
> 1) Adds -W option so we can wait on a rescan completing without starting one.
> 2) Adds qgroup information to &#
On 2/22/18 6:34 PM, Qu Wenruo wrote:
>
>
> On 2018年02月23日 06:44, Jeff Mahoney wrote:
>> On 12/22/17 1:18 AM, Qu Wenruo wrote:
>>> Unlike reservation calculation used in inode rsv for metadata, qgroup
>>> doesn't really need to care things like csum size
inode->csum_bytes);
> reserve_size += btrfs_calc_trans_metadata_size(fs_info,
> csum_leaves);
> + /*
> + * For qgroup rsv, the calculation is very simple:
> + * nodesize for each outstanding extent.
> + * This is already overkilled under most case.
> + */
> + qgroup_rsv_size = outstanding_extents * fs_info->nodesize;
>
> spin_lock(&block_rsv->lock);
> block_rsv->size = reserve_size;
> + block_rsv->qgroup_rsv_size = qgroup_rsv_size;
> spin_unlock(&block_rsv->lock);
> }
>
> @@ -8405,7 +8438,7 @@ static void unuse_block_rsv(struct btrfs_fs_info
> *fs_info,
> struct btrfs_block_rsv *block_rsv, u32 blocksize)
> {
> block_rsv_add_bytes(block_rsv, blocksize, 0);
> - block_rsv_release_bytes(fs_info, block_rsv, NULL, 0);
> + block_rsv_release_bytes(fs_info, block_rsv, NULL, 0, NULL);
> }
>
> /*
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 2/21/18 8:36 PM, Qu Wenruo wrote:
>
>
> On 2018年02月22日 04:19, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> There are several places where we call btrfs_qgroup_reserve_meta and
>> assume that a return value of 0 means that the reservation was successful.
On 1/29/18 2:58 PM, Liu Bo wrote:
> On Mon, Jan 29, 2018 at 11:46:28AM -0500, Jeff Mahoney wrote:
>> btrfs_evict_inode must clear all inodes or we'll hit a BUG_ON in evict().
>>
>> Fixes: 3d48d9810de (btrfs: Handle uninitialised inode eviction)
>> Cc: Nikolay Boriso
btrfs_evict_inode must clear all inodes or we'll hit a BUG_ON in evict().
Fixes: 3d48d9810de (btrfs: Handle uninitialised inode eviction)
Cc: Nikolay Borisov
Cc: # v4.8+
Signed-off-by: Jeff Mahoney
---
fs/btrfs/inode.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/inode.c
+++
On 11/20/17 11:04 PM, Chris Murphy wrote:
> On Mon, Nov 20, 2017 at 6:46 PM, Jeff Mahoney wrote:
>> On 11/20/17 5:59 PM, Chris Murphy wrote:
>>> On Mon, Nov 20, 2017 at 1:40 PM, Jeff Mahoney wrote:
>>>> On 11/20/17 3:01 PM, Jeff Mahoney wrote:
>>>>
On 11/20/17 5:59 PM, Chris Murphy wrote:
> On Mon, Nov 20, 2017 at 1:40 PM, Jeff Mahoney wrote:
>> On 11/20/17 3:01 PM, Jeff Mahoney wrote:
>>> On 11/20/17 3:00 PM, Jeff Mahoney wrote:
>>>> On 11/19/17 4:38 PM, Chris Murphy wrote:
>>>>> On Sa
On 11/20/17 3:01 PM, Jeff Mahoney wrote:
> On 11/20/17 3:00 PM, Jeff Mahoney wrote:
>> On 11/19/17 4:38 PM, Chris Murphy wrote:
>>> On Sat, Nov 18, 2017 at 11:27 PM, Andrei Borzenkov
>>> wrote:
>>>> 19.11.2017 09:17, Chris Murphy пишет:
>>>>
On 11/20/17 3:00 PM, Jeff Mahoney wrote:
> On 11/19/17 4:38 PM, Chris Murphy wrote:
>> On Sat, Nov 18, 2017 at 11:27 PM, Andrei Borzenkov
>> wrote:
>>> 19.11.2017 09:17, Chris Murphy пишет:
>>>> fstrim should trim free space, but it only trims unallocated. Thi
On 10/24/17 8:29 AM, Jeff Mahoney wrote:
> On 10/24/17 7:51 AM, Qu Wenruo wrote:
>>
>>
>> On 2017年10月24日 19:00, Nikolay Borisov wrote:
>>> nit: Why not BTRFS_QGROUP_RSV_TYPES_MAX = 2;
>>
>> My original plan is just as the same as yours.
>>
>&
oup, organized in fs_info->qgroup_tree.
>>> */
>>> @@ -88,6 +108,7 @@ struct btrfs_qgroup {
>>> * reservation tracking
>>> */
>>> u64 reserved;
>>> + struct btrfs_qgroup_rsv rsv;
>>>
>>> /*
>>> * lists
>>> @@ -228,12 +249,14 @@ int btrfs_qgroup_inherit(struct btrfs_trans_handle
>>> *trans,
>>> struct btrfs_fs_info *fs_info, u64 srcid, u64 objectid,
>>> struct btrfs_qgroup_inherit *inherit);
>>> void btrfs_qgroup_free_refroot(struct btrfs_fs_info *fs_info,
>>> - u64 ref_root, u64 num_bytes);
>>> + u64 ref_root, u64 num_bytes,
>>> + enum btrfs_qgroup_rsv_type type);
>>> static inline void btrfs_qgroup_free_delayed_ref(struct btrfs_fs_info
>>> *fs_info,
>>> u64 ref_root, u64 num_bytes)
>>> {
>>> trace_btrfs_qgroup_free_delayed_ref(fs_info, ref_root, num_bytes);
>>> - btrfs_qgroup_free_refroot(fs_info, ref_root, num_bytes);
>>> + btrfs_qgroup_free_refroot(fs_info, ref_root, num_bytes,
>>> + BTRFS_QGROUP_RSV_DATA);
>>> }
>>>
>>> #ifdef CONFIG_BTRFS_FS_RUN_SANITY_TESTS
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
t; https://bugs.launchpad.net/bugs/1717443
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 10/11/17 2:20 PM, Ian Kumlien wrote:
>
>
> On Wed, Oct 11, 2017 at 2:10 PM Jeff Mahoney <mailto:je...@suse.com>> wrote:
>
> On 10/11/17 12:41 PM, Ian Kumlien wrote:
>
> [--8<--]
>
> > Eventually the filesystem becomes read-only and everyt
really intended
for single spinning disks to get a little bit more resiliency in the
face of bad sectors.
The check error above means that it wasn't able to map a logical address
to a physical address. Typically that means that the mapping was lost.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
e btrfs
report the proper anon dev_t in stat and
> everything will just work.
We do. We did then too. But what doesn't work is a user doing stat()
and then using the dev_t to call ustat().
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
root(struct btrfs_trans_handle *trans,
> struct btrfs_root
> out:
> btrfs_free_path(path);
> return ret;
> +abort_transaction:
> + btrfs_abort_transaction(trans, ret);
> + goto out;
> }
>
> int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root
> *root,
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
->name_len);
> if (ret < 0) {
> +free_path:
> fs_path_free(new_path);
> return ret;
> }
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
}
>
> ret = add_to_free_space_tree(trans, info, bytenr, num_bytes);
> - if (ret) {
> - btrfs_abort_transaction(trans, ret);
> - goto out;
> - }
> + if (ret)
> + goto abort_transaction;
root, path, del_slot, del_nr);
> - if (ret < 0) {
> - btrfs_abort_transaction(trans, ret);
> - goto out;
> - }
> + if (ret < 0)
> + goto abort_transaction;
> }
> out:
> btrfs_free_path(path);
> return 0;
> +e_inval:
> + ret = -EINVAL;
> +abort_transaction:
> + btrfs_abort_transaction(trans, ret);
> + goto out;
> }
>
> /*
>
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
btrfs_del_roots always uses the tree_root. Let's pass fs_info instead.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/ctree.h | 4 ++--
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/free-space-tree.c | 2 +-
fs/btrfs/qgroup.c | 3 +--
fs/btrfs/root-tree.c | 7 ---
5
On 8/2/17 3:54 PM, je...@suse.com wrote:
> From: Jeff Mahoney
>
> btrfs_find_root and btrfs_del_root always use the tree_root. Let's pass
> fs_info instead.
This one is broken. btrfs_read_fs_root is called during log tree
recovery with the log_root_tree. I'll send an
to the proposed scripted implementation.
>
> The workflow is simple:
> - copy kernel mktables.c changes to btrfs-progs mktables.c
> - compile mktables
> - run 'make kernel-lib/tables.c'
Can't this happen as part of a make dist (that we don't do right now)?
> - commit the changes to git
... and anyone using the git repo directly can sort out how to build it?
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
that's probably why we haven't seen this issue sooner.
There's potential for this to happen whenever two threads are modifying
the tree at once and one needs to find a free extent. I'll need to
think a bit on how to fix it.
-Jeff
> Best regards,
> Angel
>
> On Mon,
On 8/7/17 1:19 PM, Jeff Mahoney wrote:
> On 8/7/17 10:12 AM, Angel Shtilianov wrote:
>> Hi there,
>> I'm investigating sporadic hanging during btrfs umount. The FS is
>> contained in a loop mounted file.
>> I have no reproduction scenario and the issue may happen o
gt; }
>
> The complete backtraces could be found in the attached log.
>
> Do you have any ideas ?
Hi Angel -
In your log, it says lockdep is disabled. What tripped it earlier?
Lockdep really should be catching locking deadlocks in situations like
this, if that's really the underlying cause.
-Jeff
--
Jeff Mahoney
SUSE Labs
signature.asc
Description: OpenPGP digital signature
On 7/27/17 9:27 PM, Qu Wenruo wrote:
>
>
> On 2017年07月27日 23:47, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> The dd in convert-tests/008-readonly-image is expected to fail, so
>> there being a typo in the file name has gone unnoticed.
>
> T
On 7/27/17 12:38 PM, Jeff Mahoney wrote:
> On 7/26/17 9:35 PM, Qu Wenruo wrote:
>>
>>
>> On 2017年07月26日 04:54, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate
>>
On 7/26/17 9:35 PM, Qu Wenruo wrote:
>
>
> On 2017年07月26日 04:54, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate
>> the available space) changed how we handle migrating file data so
On 7/26/17 9:22 AM, Jeff Mahoney wrote:
> On 7/26/17 3:08 AM, Nikolay Borisov wrote:
>>
>>
>> On 25.07.2017 23:51, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> ---
>>> backref.c | 11 +++
>>> 1 file changed
On 7/26/17 3:08 AM, Nikolay Borisov wrote:
>
>
> On 25.07.2017 23:51, je...@suse.com wrote:
>> From: Jeff Mahoney
>>
>> ---
>> backref.c | 11 +++
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/backref.c b/
1 - 100 of 820 matches
Mail list logo
