Re: [PATCH 0/4] btrfs: update qgroups in drop snapshot

Mark Fasheh wrote on 2015/09/23 14:49 -0700: On Wed, Sep 23, 2015 at 09:40:42AM +0800, Qu Wenruo wrote: Thanks for all your work on this. Comment on test case is inlined below. No problem, thanks for the review Qu! +# Create an fs tree of a given height at a target location. This is +#

[PATCH 0/2] progress indicator for btrfs-check

Hello btrfs, I have noticed that a long running process like "btrfs check" needs a progress indicator. Please look into these patches. Besides that I have found a problem with the task struct id value which is a pthread_t and not be set to -1. Thanks for the review and eventual inclusion of

[PATCH 1/2] btrfs-progs: tasks info->id is a pthread_t and should not set to -1

Signed-off-by: Silvio Fricke --- task-utils.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/task-utils.c b/task-utils.c index 58f5195..a4017ff 100644 --- a/task-utils.c +++ b/task-utils.c @@ -51,7 +51,7 @@ int task_start(struct task_info *info)

[PATCH 2/2] btrfs-progs: check: add progress indicator

Signed-off-by: Silvio Fricke --- cmds-check.c | 93 +--- 1 file changed, 89 insertions(+), 4 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index fe3f782..00423af 100644 --- a/cmds-check.c +++ b/cmds-check.c

Re: [BUG] kernel BUG at fs/btrfs/extent_io.c:2062 (v4.2.0-rc8)

2015-09-01 3:08 GMT+03:00 Dāvis Mosāns : > > Here's a btrfs-image from that filesystems /dev/sdb > https://drive.google.com/file/d/0B82_Tz1_6URAQmV5LTZHUmR4YXM/view?usp=sharing > sha256sum > 88fb561b4a581319ae18c1f27b6ac108e9c08ff80954e192cb3201cc5d4c19ff raid1_sdb.img > size

strange i/o errors with btrfs on raid/lvm

Hi all, We experience strange Input/output errors on our mail server (dovecot pop/imap) that is using btrfs for its mailspool. The server uses software RAID10. The RAID is split into LVMs. The mailspool logical volume uses btrfs. For several days now we see Input/output errors on different

[PATCH] Btrfs: add a flags field to btrfs_transaction

I want to set some per transaction flags, so instead of adding yet another int lets just convert the current two int indicators to flags and add a flags field for future use. Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 5 +++-- fs/btrfs/transaction.c | 18

Re: FYIO: A rant about btrfs

On 18 September 2015 at 14:10, Austin S Hemmelgarn wrote: > On 2015-09-17 10:52, Aneurin Price wrote: >> >> On 16 September 2015 at 20:21, Austin S Hemmelgarn >> wrote: >>> >>> ZFS has been around for much longer, it's been mature and feature >>>

Re: btrfs: obtain block checksums from user space

On 2015-09-24 14:48, Matwey V. Kornilov wrote: 2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn : On 2015-09-24 14:06, Matwey V. Kornilov wrote: Hello, I would like to read the list of the checksums for the specific file stored onto btrfs filesystem. I think I could use

Re: strange i/o errors with btrfs on raid/lvm

On Thu, Sep 24, 2015 at 8:34 AM, Jogi Hofmüller wrote: > All this runs on a virtual machine that uses kernel 4.1.3 (Debian build) > and btrfs-progs v4.0. Unrelated to the problem but I'd upgrade progs, in case it's ever needed. 4.1 and 4.2 have tons of bug fixes over 4.0 already.

Re: btrfs: obtain block checksums from user space

2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn : > On 2015-09-24 14:06, Matwey V. Kornilov wrote: >> >> >> Hello, >> >> I would like to read the list of the checksums for the specific file >> stored onto btrfs filesystem. I think I could use the checksums in the >> manner

btrfs: obtain block checksums from user space

Hello, I would like to read the list of the checksums for the specific file stored onto btrfs filesystem. I think I could use the checksums in the manner like rsync does, but safe both CPU (because csums are already calculated for the file) and I/O (because I don't need to reread all the file

Re: btrfs: obtain block checksums from user space

On 2015-09-24 14:06, Matwey V. Kornilov wrote: Hello, I would like to read the list of the checksums for the specific file stored onto btrfs filesystem. I think I could use the checksums in the manner like rsync does, but safe both CPU (because csums are already calculated for the file) and

[PATCH] Btrfs: change how we wait for pending ordered extents

We have a mechanism to make sure we don't lose updates for ordered extents that were logged in the transaction that is currently running. We add the ordered extent to a transaction list and then the transaction waits on all the ordered extents in that list. However are substantially large file

Re: Latest kernel to use?

On Thu, Sep 24, 2015 at 11:07:32PM +0200, Sjoerd wrote: > Maybe a silly question for most of you, but the wiki states to always try to > use the latest kernel with btrfs. Which one would be best: > - 4.2.1 (currently latest stable and matches the btrfs-progs versioning) or > - the 4.3.x

Latest kernel to use?

Maybe a silly question for most of you, but the wiki states to always try to use the latest kernel with btrfs. Which one would be best: - 4.2.1 (currently latest stable and matches the btrfs-progs versioning) or - the 4.3.x (mainline)? Stable sounds more stable to me(hence the name ;) ), but

[PATCH 2/2] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan

Ancient qgroup code call memcpy() on a extent buffer and use it for leaf iteration. As extent buffer contains lock, pointers to pages, it's never sane to do such copy. The following bug may be caused by this insane operation: [92098.841309] general protection fault: [#1] SMP [92098.841338]

[PATCH 0/2] Btrfs: Fix a insane extent_buffer copy behavior for qgroup

Stephane Lesimple reported an qgroup rescan bug: [92098.841309] general protection fault: [#1] SMP [92098.841338] Modules linked in: ... [92098.841814] CPU: 1 PID: 24655 Comm: kworker/u4:12 Not tainted 4.3.0-rc1 #1 [92098.841868] Workqueue: btrfs-qgroup-rescan btrfs_qgroup_rescan_helper

[PATCH 1/2] btrfs: Add support to do stack item key operation

Normal btrfs_item_key_to_cpu() will need extent buffer to do it, and there is not stack version to handle in memory leaf. Add btrfs_stack_item_key_to_cpu() function for such operation, which will provide the basis for later qgroup fix. Signed-off-by: Qu Wenruo ---

[PATCH v2 2/2] btrfs: reada: Fix returned errno code

reada is using -1 instead of the -ENOMEM defined macro to specify that a buffer allocation failed. Since the error number is propagated, the caller will get a -EPERM which is the wrong error condition. Also, updating the caller to return the exact value from reada_add_block. Smatch tool warning:

[PATCH v2 0/2] btrfs: Fix returned errno codes

Hi, These two patches fix instances where -1 is used to specify a buffer allocation fail, instead of using -ENOMEM. Patch 1/2 is already reviewed by David Sterba. Luis de Bethencourt (2): btrfs: check-integrity: Fix returned errno codes btrfs: reada: Fix returned errno code

Re: [PATCH 0/4] btrfs: update qgroups in drop snapshot

Mark Fasheh wrote on 2015/09/22 13:15 -0700: Hi, The following 4 patches fix a regression introduced in Linux 4.2 where btrfs_drop_snapshot() wasn't updating qgroups, resulting in them going bad. The original e-mail pointing this out is below: