[btrfs-progs 1/4] Add man/mkfs.btrfs.8.in

Add man/mkfs.btrfs.8.in Kept the name with the name in, so that further processing such as BUILD_DATE BUILD_VERSION etc. could be included later. All man pages included in the man directory to avoid file cluttering. Signed-off-by: Goldwyn Rodrigues rgold...@suse.de --- man/mkfs.btrfs.8

[btrfs-progs 4/4] Modify Makefile to include man directory

Signed-off-by: Goldwyn Rodrigues rgold...@gmail.com --- Makefile | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3349079..8f21c27 100644 --- a/Makefile +++ b/Makefile @@ -30,7 +30,7 @@ endif $(CC) $(DEPFLAGS) $(AM_CFLAGS

Re: [PATCH] Btrfs: Fix balance panic

Hello Helmut, On Wed, Jan 26, 2011 at 9:33 AM, Helmut Hullen hul...@t-online.de wrote: Sorry - didn't solve my problem: -- last lines from dmesg --- bio too big device sdc (256 240) bio too big device sdc (256 240) [...] more than 800 such lines bio too big

Re: btrfs: relocation: Fix leaking qgroups numbers on data extents

On 07/29/2016 08:06 PM, Qu Wenruo wrote: > Hi, Goldwyn, > > This patch is replaced by the following patchset: > https://patchwork.kernel.org/patch/9213915/ > https://patchwork.kernel.org/patch/9213913/ > > Would you mind testing the new patch? > Sorry, it fails. Actually, the previous patch

Re: [PATCH v2 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

Thanks Qu, This patch set fixes all the reported problems. However, I have some minor issues with coding style. On 08/04/2016 09:29 PM, Qu Wenruo wrote: > Refactor btrfs_qgroup_insert_dirty_extent() function, to two functions: > 1. _btrfs_qgroup_insert_dirty_extent() >Almost the same with

Re: [PATCH v2 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

Thanks Qu, This patch set fixes all the reported problems. However, I have some minor issues with coding style. On 08/04/2016 09:29 PM, Qu Wenruo wrote: > Refactor btrfs_qgroup_insert_dirty_extent() function, to two functions: > 1. _btrfs_qgroup_insert_dirty_extent() >Almost the same with

Re: [PATCH v2 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

On 08/08/2016 08:12 PM, Qu Wenruo wrote: > > > At 08/09/2016 09:01 AM, Goldwyn Rodrigues wrote: >> >> >> On 08/08/2016 07:26 PM, Qu Wenruo wrote: >>> >>> >>> At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: >>>> >>>>

Re: [PATCH v2 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

On 08/08/2016 07:26 PM, Qu Wenruo wrote: > > > At 08/08/2016 10:54 AM, Goldwyn Rodrigues wrote: >> >> >> On 08/07/2016 07:39 PM, Qu Wenruo wrote: >>> >>> >>> At 08/07/2016 01:19 AM, Goldwyn Rodrigues wrote: >>>> Thanks Qu, &g

Re: [PATCH v3 2/3] btrfs: relocation: Fix leaking qgroups numbers on data extents

ll account these data extents correctly. > > Cc: Mark Fasheh <mfas...@suse.de> > Reported-by: Mark Fasheh <mfas...@suse.de> > Reported-by: Filipe Manana <fdman...@gmail.com> > Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com> Tested-by: Goldwyn Rodrigues <rgold...

Re: [PATCH v3 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

d comment for both functions, to info developers how to keep > qgroup correct when doing hacks. > > Cc: Mark Fasheh <mfas...@suse.de> > Cc: Goldwyn Rodrigues <rgold...@suse.de> > Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com> Reviewed-and-Tested-by: Goldwyn Rodrigue

Re: [PATCH v3 3/3] btrfs: qgroup: Fix qgroup incorrectness caused by log replay

e bug can be detected by btrfs/119 test case. > > Cc: Mark Fasheh <mfas...@suse.de> > Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com> Reviewed-and-Tested-by: Goldwyn Rodrigues <rgold...@suse.com> > --- > fs/btrfs/tree-log.c | 16 > 1 file

Re: [PATCH v2 1/3] btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()

On 08/07/2016 07:39 PM, Qu Wenruo wrote: > > > At 08/07/2016 01:19 AM, Goldwyn Rodrigues wrote: >> Thanks Qu, >> >> This patch set fixes all the reported problems. However, I have some >> minor issues with coding style. >> > > Thanks for the tes

Re: btrfs: relocation: Fix leaking qgroups numbers on data extents

sult. > > And thanks to the new qgroup framework, we don't need to check whether > it is needed to dirty some file extents. Even some unrelated extents are > re-dirtied, qgroup can handle it quite well. > > So we only need to ensure we don't miss some extents. > > Reported

Re: Very slow balance / btrfs-transaction

On 02/03/2017 04:13 PM, j...@capsec.org wrote: > Hi, > > > I'm currently running a balance (without any filters) on a 4 drives raid1 > filesystem. The array contains 3 3TB drives and one 6TB drive; I'm running > the rebalance because the 6TB drive recently replaced a 2TB drive. > > > I

Re: Very slow balance / btrfs-transaction

On 02/03/2017 06:30 PM, Jorg Bornschein wrote: > February 3, 2017 11:26 PM, "Goldwyn Rodrigues" <rgold...@suse.com> wrote: > >>> Hi, >>> >>> I'm currently running a balance (without any filters) on a 4 drives raid1 >>> filesystem.

Re: Very slow balance / btrfs-transaction

Hi Qu, On 02/05/2017 07:45 PM, Qu Wenruo wrote: > > > At 02/04/2017 09:47 AM, Jorg Bornschein wrote: >> February 4, 2017 1:07 AM, "Goldwyn Rodrigues" <rgold...@suse.de> wrote: >> >> >> Quata support was indeed active -- and it

[PATCH] btrfs-progs: Remove unused function arg in delete_extent_records

From: Goldwyn Rodrigues <rgold...@suse.com> new_len is not used in delete_extent_records(). Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- cmds-check.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 84e1d99..9f

Re: gdb log of crashed "btrfs-image -s"

On 01/18/2017 02:11 PM, Christoph Groth wrote: > Goldwyn Rodrigues wrote: >> Thanks Christoph for the backtrace. I am unable to reproduce it, but >> looking at your backtrace, I found a bug. Would you be able to give it >> a try and check if it fixes the problem? >

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

On 02/19/2017 11:35 PM, Qu Wenruo wrote: > > > At 02/20/2017 12:35 PM, Goldwyn Rodrigues wrote: >> Hi Qu, >> >> On 02/19/2017 09:07 PM, Qu Wenruo wrote: >>> >>> >>> At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: >>>> F

Why is btrfs_run_delayed_refs() run multiple times

Hi, Why do we call btrfs_run_delayed_refs multiple times in a function? Some of the examples are: btrfs_commit_transaction() commit_cowonly_roots() Is it because one call can generate more delayed refs and hence we need to run them again? Under what scenarios is this possible? -- Goldwyn --

[PATCH] qgroup: Retry after commit on getting EDQUOT

From: Goldwyn Rodrigues <rgold...@suse.com> We are facing the same problem with EDQUOT which was experienced with ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but here is a fix. Let me know if it is too big a hammer. Quotas are reserved during the start of an ope

[PATCH] qgroup: Add trace events for reserve and free_ref_root

From: Goldwyn Rodrigues <rgold...@suse.com> These commits show the current value of qg->reserved and the amount modified. Though these are frequently called function, we may require to monitor qg->reserved for some operations. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

Hi Qu, On 02/19/2017 09:07 PM, Qu Wenruo wrote: > > > At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues <rgold...@suse.com> >> >> We are facing the same problem with EDQUOT which was experienced with >> ENOSPC. Not sur

[PATCH 7/7] nonblocking aio: btrfs

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail + i_rwsem is lockable + NODATACOW or PREALLOC is set + Can nocow at the desired location + Writing beyond end of file Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- fs/btrfs/

Re: [PATCH v3] btrfs-progs: Fix disable backtrace assert error

> ASSERT/WARN_ON/BUG(), so we don't need to pass 3 different conditions > but only one. > > Also, move WARN_ON() out of the ifdef branch, as it's completely the > same for both branches. > > Cc: Goldwyn Rodrigues <rgold...@suse.de> > Signed-off-by: Qu Wenruo <quwen.

Re: gdb log of crashed "btrfs-image -s"

On 01/18/2017 01:13 AM, Christoph Groth wrote: > Christoph Groth wrote: >> Chris Murphy wrote: >>> On Tue, Jan 17, 2017 at 1:25 PM, Christoph Groth >>> wrote: Any ideas on what could be done? If you need help to debug the problem with btrfs-image,

Re: [PATCH v3] btrfs-progs: Fix disable backtrace assert error

On 01/18/2017 06:27 PM, Qu Wenruo wrote: > > > At 01/18/2017 07:38 PM, Goldwyn Rodrigues wrote: >> >> >> On 01/17/2017 09:04 PM, Qu Wenruo wrote: >>> Due to commit 00e769d04c2c83029d6c71(btrfs-progs: Correct value printed >>> by assertions/BU

Re: Unocorrectable errors with RAID1

On 01/17/2017 02:25 PM, Christoph Groth wrote: > Goldwyn Rodrigues wrote: >> On 01/17/2017 02:44 AM, Christoph Groth wrote: >>> Goldwyn Rodrigues wrote: >>> >>>> Would you be able to upload a btrfs-image for me to examine. This is a >>>

Re: Unocorrectable errors with RAID1

On 01/17/2017 02:44 AM, Christoph Groth wrote: > Goldwyn Rodrigues wrote: > >> Would you be able to upload a btrfs-image for me to examine. This is a >> core ctree error where most probably item size is incorrectly registered. > > Sure, I can do that. I'd l

Re: Unocorrectable errors with RAID1

On 01/16/2017 05:10 AM, Christoph Groth wrote: > Hi, > > I’ve been using a btrfs RAID1 of two hard disks since early 2012 on my > home server. The machine has been working well overall, but recently > some problems with the file system surfaced. Since I do have backups, I > do not worry about

[PATCH] btrfs-progs: sanitize - Use correct source for memcpy

From: Goldwyn Rodrigues <rgold...@suse.com> While performing a memcpy, we are copying from uninitialized dst as opposed to src->data. Though using eb->len is correct, I used src->len to make it more readable. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- image/

[PATCH 8/8] nowait aio: btrfs

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail + i_rwsem is not lockable + NODATACOW or PREALLOC is not set + Cannot nocow at the desired location + Writing beyond end of file which is not allocated Signed-off-by: Goldwyn Rodrigues

[PATCH 4/8] nowait aio: Introduce IOMAP_NOWAIT

From: Goldwyn Rodrigues <rgold...@suse.com> IOCB_NOWAIT translates to IOMAP_NOWAIT for iomaps. This is used by XFS in the XFS patch. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- fs/iomap.c| 2 ++ include/linux/iomap.h | 1 + 2 files changed, 3 insertions(+)

[PATCH 3/8] nowait aio: return if direct write will trigger writeback

From: Goldwyn Rodrigues <rgold...@suse.com> Find out if the write will trigger a wait due to writeback. If yes, return -EAGAIN. This introduces a new function filemap_range_has_page() which returns true if the file's mapping has a page within the range mentioned. Return -EINVAL for buffer

[PATCH 0/8 v2] Non-blocking AIO

This series adds nonblocking feature to asynchronous I/O writes. io_submit() can be delayed because of a number of reason: - Block allocation for files - Data writebacks for direct I/O - Sleeping because of waiting to acquire i_rwsem - Congested block device The goal of the patch series is to

[PATCH 7/8] nowait aio: xfs

From: Goldwyn Rodrigues <rgold...@suse.com> If IOCB_NOWAIT is set, bail if the i_rwsem is not lockable immediately. IF IOMAP_NOWAIT is set, return EAGAIN in xfs_file_iomap_begin if it needs allocation either due to file extending, writing to a hole, or COW. Signed-off-by: Goldwyn Rod

[PATCH 5/8] nowait aio: return on congested block device

From: Goldwyn Rodrigues <rgold...@suse.com> A new flag BIO_NOWAIT is introduced to identify bio's orignating from iocb with IOCB_NOWAIT. This flag indicates to return immediately if a request cannot be made instead of retrying. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --

[PATCH 6/8] nowait aio: ext4

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail for direct I/O: + i_rwsem is lockable + Writing beyond end of file (will trigger allocation) + Blocks are not allocated at the write location Signed-off-by: Goldwyn Rodrigues <rgold...

[PATCH 1/8] nowait aio: Introduce IOCB_FLAG_NOWAIT

From: Goldwyn Rodrigues <rgold...@suse.com> This flag informs kernel to bail out if an AIO request will block for reasons such as file allocations, or a writeback triggered, or would block while allocating requests while performing direct I/O. IOCB_FLAG_NOWAIT is translated to IOCB_

[PATCH 2/8] nowait aio: Return if cannot get hold of i_rwsem

From: Goldwyn Rodrigues <rgold...@suse.com> A failure to lock i_rwsem would mean there is I/O being performed by another thread. So, let's bail. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- mm/filemap.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) dif

Re: [PATCH 1/8] nowait aio: Introduce IOCB_FLAG_NOWAIT

On 03/01/2017 09:56 AM, Christoph Hellwig wrote: > On Wed, Mar 01, 2017 at 07:36:48AM -0800, Christoph Hellwig wrote: >> Given that we aren't validating aio_flags in older kernels we can't >> just add this flag as it will be a no-op in older kernels. I think >> we will have to add

Re: [PATCH] btrfs: relocation: Fix NULL pointer access and leaking qgroups in btrfs_recover_relocation

On 10/06/2016 09:32 PM, Qu Wenruo wrote: > > > At 10/07/2016 02:00 AM, Goldwyn Rodrigues wrote: >> Hi Qu, >> >> On 10/06/2016 03:03 AM, Qu Wenruo wrote: >>> We fixed balance qgroup leaking by introducing >>> qgroup_fix_relocated_data_extents(),

Re: [PATCH] btrfs: relocation: Fix NULL pointer access and leaking qgroups in btrfs_recover_relocation

a /boot $S; done; #let the cp from above finish wait btrfs fi sync $MNT btrfs quota enable $MNT btrfs quota rescan -w $MNT btrfs qg show $MNT umount $MNT mount -t btrfs $DEV $MNT time btrfs balance start --full-balance $MNT umount $MNT btrfsck $DEV > > Reported-by: Go

Re: [PATCH v3.1 2/3] btrfs: relocation: Fix leaking qgroups numbers on data extents

c tree. > Since at commit transaction time, the tree swapping is done, and qgroup > will account these data extents correctly. > > Cc: Mark Fasheh <mfas...@suse.de> > Reported-by: Mark Fasheh <mfas...@suse.de> > Reported-by: Filipe Manana <fdman...@gmail.com> >

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

On 09/26/2016 10:10 PM, Qu Wenruo wrote: > > > At 09/26/2016 10:31 PM, Goldwyn Rodrigues wrote: >> >> >> On 09/25/2016 09:33 PM, Qu Wenruo wrote: >>> >>> >>> At 09/23/2016 09:43 PM, Goldwyn Rodrigues wrote: >>>> >>>&g

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

On 09/29/2016 03:57 AM, Qu Wenruo wrote: > Thanks for your test script. > > I succeeded in pinning down the problem. > > The problem is, btrfs is invalidate pages that belongs to ordered > extent(goes through writeback) No, I don't think invalidated pages are going through writeback. The

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

On 09/27/2016 08:44 PM, Qu Wenruo wrote: > Finally reproduced it. > > Although in a low chance, about 1/10. > > Under most case, the final remove gets executed without error. Change 50m to 500m while setting the qgroup limit, the probability will increase. -- Goldwyn -- To unsubscribe

[PATCH] qgroup: Prevent qgroup->reserved from going subzero

From: Goldwyn Rodrigues <rgold...@suse.com> While free'ing qgroup->reserved resources, we much check if the page has not been invalidated by a truncate operation by checking if the page is still dirty before reducing the qgroup resources. Resources in such a case are free'd when the enti

Re: [PATCH 1/2] btrfs: Add WARN_ON for qgroup reserved underflow

u Wenruo <quwen...@cn.fujitsu.com> Looks good. Reviewed-by: Goldwyn Rodrigues <rgold...@suse.com> > --- > fs/btrfs/qgroup.c | 21 - > 1 file changed, 16 insertions(+), 5 deletions(-) > > diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c > index 8db2e29..853258

Re: [PATCH 2/2] btrfs: Add trace point for qgroup reserved space

vent. > > Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com> Reviewed-by: Goldwyn Rodrigues <rgold...@suse.com> > --- > fs/btrfs/qgroup.c| 21 ++--- > fs/btrfs/qgroup.h| 2 +- > include/trace/events/btrfs.h | 43 +++

[PATCH] btrfs-progs: repair: Trickle down EEXISTS while freeing

0, refs_to_drop=refs_to_drop@entry=1) at extent-tree.c:2410 #6 del_pending_extents (trans=trans@entry=0x7e7240, extent_root=0x6a88a0) at extent-tree.c:2448 Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> diff --git a/extent-tree.c b/extent-tree.c index 3b1577e..a21e369 100644 --- a/ex

Re: [PATCH] btrfs-progs: repair: Trickle down EEXISTS while freeing

On 10/28/2016 09:42 AM, David Sterba wrote: > On Thu, Oct 27, 2016 at 01:05:08PM -0500, Goldwyn Rodrigues wrote: >> While deleting pending extents, we insert extents to the >> extent_tree. However, because of corruption, this might already >> be freed. We trickle the

Re: [PATCH 0/4] Qgroup comment enhance and balance fix

On 10/27/2016 07:33 PM, Qu Wenruo wrote: > Any comment? > > Especially the final patch will fix a long standing bug. > While I have tested it, and it works, I did not get time to review it. So, you can have my Tested-by: Goldwyn Rodrigues <rgold...@suse.com> > Thank

[PATCH] Return best entry, if it is the first one

. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- cmds-check.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 368c1c5..779870a 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -8184,11 +8184,6 @@ static struct extent

[PATCH] btrfs-progs: Fix extents after finding all errors

to show all errors and then fix the extents. Set a variable and call fixup_extent_ref() if it is set. err is not used, so cleared it. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- cmds-check.c | 75 +++- 1 file changed, 24 inse

[PATCH] btrfs-progs: Initialize btrfs_path before use

From: Goldwyn Rodrigues <rgold...@suse.com> While performing an fsck, an assertion failure occurs because of reusing path in a loop. ctree.c:1112: btrfs_search_slot: Warning: assertion `p->nodes[0] != NULL` failed, value 0 Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> di

Re: [PATCH] btrfs-progs: Initialize btrfs_path before use

On 10/24/2016 09:57 AM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues <rgold...@suse.com> > > While performing an fsck, an assertion failure occurs because of reusing path > in a loop. > ctree.c:1112: btrfs_search_slot: Warning: assertion `p->nodes[0] !=

[PATCH] Release path after usage.

From: Goldwyn Rodrigues <rgold...@suse.com> While performing an fsck, an assertion failure occurs because of reusing path in a loop. ctree.c:1112: btrfs_search_slot: Warning: assertion `p->nodes[0] != NULL` failed, value 0 Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com&g

Re: [PATCH 2/4] btrfs: qgroup: Rename functions to make it follow reserve,trace,account steps

Reviewed-and-Tested-by: Goldwyn Rodrigues <rgold...@suse.com> On 10/17/2016 08:31 PM, Qu Wenruo wrote: > Rename btrfs_qgroup_insert_dirty_extent(_nolock) to > btrfs_qgroup_trace_extent(_nolock), according to the new > reserve/trace/account naming schema. > > Signed-off

Re: [PATCH 1/4] btrfs: qgroup: Add comments explaining how btrfs qgroup works

Reviewed-by: Goldwyn Rodrigues <rgold...@suse.com> On 10/17/2016 08:31 PM, Qu Wenruo wrote: > Add explain how btrfs qgroup works. > > Qgroup is split into 3 main phrases: > 1) Reserve >To ensure qgroup doesn't exceed its limit > > 2) Trace >To info qgrou

Re: [PATCH 4/4] btrfs: qgroup: Fix qgroup data leaking by using subtree tracing

Reviewed-and-Tested-by: Goldwyn Rodrigues <rgold...@suse.com> On 10/17/2016 08:31 PM, Qu Wenruo wrote: > Commit 62b99540a1d91e464 (btrfs: relocation: Fix leaking qgroups numbers > on data extents) only fixes the problem partly. > > The previous fix is to trace all new data exte

Re: [PATCH 3/4] btrfs: Expoert and move leaf/subtree qgroup helpers to qgroup.c

Reviewed-and-Tested-by: Goldwyn Rodrigues <rgold...@suse.com> On 10/17/2016 08:31 PM, Qu Wenruo wrote: > Move account_shared_subtree() to qgroup.c and rename it to > btrfs_qgroup_trace_subtree(). > > Do the same thing for account_leaf_items() and rename it to > btrfs_qg

Re: [PATCH] btrfs-progs: repair: Trickle down EEXISTS while freeing

Hi David, On 10/28/2016 09:42 AM, David Sterba wrote: > On Thu, Oct 27, 2016 at 01:05:08PM -0500, Goldwyn Rodrigues wrote: >> While deleting pending extents, we insert extents to the >> extent_tree. However, because of corruption, this might already be >> freed. We tric

Re: [RFC] Converging userspace and kernel code

On 01/10/2017 09:20 AM, Anand Jain wrote: > > > On 01/10/17 20:14, Goldwyn Rodrigues wrote: >> >> >> On 01/09/2017 09:28 PM, Anand Jain wrote: >>> >>> Goldwyn, >>> >>> Could you add a list what functionality in btrfs-progs will

Re: [RFC] Converging userspace and kernel code

On 01/10/2017 08:23 PM, Anand Jain wrote: > > > On 01/11/17 00:04, Goldwyn Rodrigues wrote: >> >> >> On 01/10/2017 09:20 AM, Anand Jain wrote: >>> >>> >>> On 01/10/17 20:14, Goldwyn Rodrigues wrote: >>>> >&

[PATCH] btrfs-progs: Initialize ret to suppress compiler warning

From: Goldwyn Rodrigues <rgold...@suse.com> Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- cmds-check.c| 2 +- qgroup-verify.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 85eaa63..a9501f5 100644 --- a/cmds-c

[PATCH] btrfs-progs: Fix extents after finding all errors

From: Goldwyn Rodrigues <rgold...@suse.com> Simplifying the logic of fixing. Calling fixup_extent_ref() after encountering every error causes more error messages after the extent is fixed. In case of multiple errors, this is confusing because the error message is displayed after the fix m

[PATCH] btrfs-progs: find_free_dev_extent() closer to kernel code

From: Goldwyn Rodrigues <rgold...@suse.com> This solves an ENOSPC issue with nearly full filesystems. The only things missing from the function is contains_pending_extent() which should not be required in this case. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- vol

[PATCH 2/2] btrfs-progs: Remove duplicate printfs in warning_trace()/assert_trace()

From: Goldwyn Rodrigues <rgold...@suse.com> Code reduction. Call warning_trace from assert_trace in order to reduce the printf's used. Also, trace variable in warning_trace() is not required because it is already handled by BTRFS_DISABLE_BACKTRACE. Signed-off-by: Goldwyn Rodrigues

[PATCH 1/2] btrfs-progs: Correct value printed by assertions/BUG_ON/WARN_ON

From: Goldwyn Rodrigues <rgold...@suse.com> The values passed to BUG_ON/WARN_ON are negated(!) and printed, which results in printing the value zero for each bug/warning. For example: volumes.c:988: btrfs_alloc_chunk: Assertion `ret` failed, value 0 This is not useful. Instead changed to

Re: [PATCH 1/2] btrfs-progs: Correct value printed by assertions/BUG_ON/WARN_ON

On 12/05/2016 08:03 PM, Qu Wenruo wrote: > BTW, the DISABLE_BACKTRACE branch seems quite different from backtrace one. > > #define BUG_ON(c) assert_trace(#c, __FILE__, __func__, __LINE__, (long)(c)) > #define WARN_ON(c) warning_trace(#c, __FILE__, __func__, __LINE__, > (long)(c)) > #define

Re: [PATCH 1/2] btrfs-progs: Correct value printed by assertions/BUG_ON/WARN_ON

= 0 > > For me, ASSERT(ret == 0) seems quite safe and common here. > Doesn't the patch changed the ASSERT() behavior? > > Thanks, > Qu > > At 11/30/2016 12:24 AM, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues <rgold...@suse.com> >> >> The val

Re: [PATCH 1/2] btrfs-progs: Correct value printed by assertions/BUG_ON/WARN_ON

On 12/05/2016 09:08 PM, Qu Wenruo wrote: > > > At 12/06/2016 10:51 AM, Goldwyn Rodrigues wrote: >> >> >> On 12/05/2016 08:03 PM, Qu Wenruo wrote: >>> BTW, the DISABLE_BACKTRACE branch seems quite different from >>> backtrace one. >>> >

Re: [RFC] Converging userspace and kernel code

On 01/08/2017 08:11 PM, Qu Wenruo wrote: > > > At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: >> >> 1. Motivation >> While fixing user space tools for btrfs-progs, I found a couple of bugs >> which are already solved in kernel space but were not po

[RFC] Converging userspace and kernel code

1. Motivation While fixing user space tools for btrfs-progs, I found a couple of bugs which are already solved in kernel space but were not ported to user space. User space is a little ignored when it comes to fixing bugs in the core functionality. XFS developers have already performed this and

Re: [RFC] Converging userspace and kernel code

and btrfs-progs. > > Thanks, Anand > > > On 01/08/17 21:16, Goldwyn Rodrigues wrote: >> >> 1. Motivation >> While fixing user space tools for btrfs-progs, I found a couple of bugs >> which are already solved in kernel space but were not ported to user

[PATCH] btrfs-progs: Get the highest inode for lost+found

From: Goldwyn Rodrigues <rgold...@suse.com> root->highest_inode is not accurate at the time of creating a lost+found and it fails because the highest_inode+1 is already present. This could be because of fixes after highest_inode is set. Instead, search for the highest inode in the tre

Re: [PATCH] btrfs-progs: Get the highest inode for lost+found

On 12/20/2016 06:57 PM, Qu Wenruo wrote: > > > At 12/20/2016 08:08 PM, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues <rgold...@suse.com> >> >> root->highest_inode is not accurate at the time of creating a lost+found >> and it fails beca

Re: [PATCH] btrfs-progs: Fix disable backtrace assert error

rigger the bug when condition is true. > > Also, move WARN_ON() out of the ifdef branch, as it's completely the > same for both branches. > > Cc: Goldwyn Rodrigues <rgold...@suse.de> > Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com> > --- > kerncompat.h | 19

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/16/2017 09:33 AM, Jens Axboe wrote: > On 03/15/2017 03:51 PM, Goldwyn Rodrigues wrote: >> diff --git a/block/blk-core.c b/block/blk-core.c >> index 0eeb99e..2e5cba2 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -2014,7 +2019,7 @@ blk_qc_

[PATCH v5] qgroup: Retry after commit on getting EDQUOT

From: Goldwyn Rodrigues <rgold...@suse.com> We are facing the same problem with EDQUOT which was experienced with ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but here is a quick fix, which may be too big a hammer. Quotas are reserved during the start of an ope

Re: [PATCH v5] qgroup: Retry after commit on getting EDQUOT

On 03/27/2017 12:36 PM, David Sterba wrote: > On Mon, Mar 27, 2017 at 12:29:57PM -0500, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues <rgold...@suse.com> >> >> We are facing the same problem with EDQUOT which was experienced with >> ENOSPC. Not sure if w

Re: [PATCH 3/8] nowait aio: return if direct write will trigger writeback

On 03/16/2017 08:08 AM, Matthew Wilcox wrote: > On Wed, Mar 15, 2017 at 04:51:02PM -0500, Goldwyn Rodrigues wrote: >> This introduces a new function filemap_range_has_page() which >> returns true if the file's mapping has a page within the range >> mentioned. > &g

Re: [PATCH 3/8] nowait aio: return if direct write will trigger writeback

On 03/16/2017 08:20 AM, Matthew Wilcox wrote: > On Wed, Mar 15, 2017 at 04:51:02PM -0500, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues <rgold...@suse.com> >> >> Find out if the write will trigger a wait due to writeback. If yes, >> return -EAGAIN. >

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/16/2017 09:33 AM, Jens Axboe wrote: > On 03/15/2017 03:51 PM, Goldwyn Rodrigues wrote: >> diff --git a/block/blk-core.c b/block/blk-core.c >> index 0eeb99e..2e5cba2 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -2014,7 +2019,7 @@ blk_qc_

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/16/2017 04:31 PM, Dave Chinner wrote: > On Wed, Mar 15, 2017 at 04:51:04PM -0500, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues <rgold...@suse.com> >> >> A new flag BIO_NOWAIT is introduced to identify bio's >> orignating from iocb with IOCB_NOWAIT.

[PATCH 0/8 v3] No wait AIO

Formerly known as non-blocking AIO. This series adds nonblocking feature to asynchronous I/O writes. io_submit() can be delayed because of a number of reason: - Block allocation for files - Data writebacks for direct I/O - Sleeping because of waiting to acquire i_rwsem - Congested block

[PATCH 6/8] nowait aio: ext4

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail for direct I/O: + i_rwsem is lockable + Writing beyond end of file (will trigger allocation) + Blocks are not allocated at the write location Signed-off-by: Goldwyn Rodrigues <rgold...

[PATCH 4/8] nowait-aio: Introduce IOMAP_NOWAIT

From: Goldwyn Rodrigues <rgold...@suse.com> IOCB_NOWAIT translates to IOMAP_NOWAIT for iomaps. This is used by XFS in the XFS patch. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- fs/iomap.c| 2 ++ include/linux/iomap.h | 1 + 2 files changed, 3 insertions(+)

[PATCH 8/8] nowait aio: btrfs

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail + i_rwsem is not lockable + NODATACOW or PREALLOC is not set + Cannot nocow at the desired location + Writing beyond end of file which is not allocated Signed-off-by: Goldwyn Rodrigues

[PATCH 7/8] nowait aio: xfs

From: Goldwyn Rodrigues <rgold...@suse.com> If IOCB_NOWAIT is set, bail if the i_rwsem is not lockable immediately. IF IOMAP_NOWAIT is set, return EAGAIN in xfs_file_iomap_begin if it needs allocation either due to file extension, writing to a hole, or COW or waiting for other DIOs to

[PATCH 5/8] nowait aio: return on congested block device

From: Goldwyn Rodrigues <rgold...@suse.com> A new flag BIO_NOWAIT is introduced to identify bio's orignating from iocb with IOCB_NOWAIT. This flag indicates to return immediately if a request cannot be made instead of retrying. Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --

[PATCH 3/8] nowait aio: return if direct write will trigger writeback

From: Goldwyn Rodrigues <rgold...@suse.com> Find out if the write will trigger a wait due to writeback. If yes, return -EAGAIN. This introduces a new function filemap_range_has_page() which returns true if the file's mapping has a page within the range mentioned. Return -EINVAL for buffer

[PATCH 1/8] nowait aio: Introduce IOCB_RW_FLAG_NOWAIT

From: Goldwyn Rodrigues <rgold...@suse.com> This flag informs kernel to bail out if an AIO request will block for reasons such as file allocations, or a writeback triggered, or would block while allocating requests while performing direct I/O. Unfortunately, aio_flags is not checked for va

[PATCH 2/8] nowait aio: Return if cannot get hold of i_rwsem

From: Goldwyn Rodrigues <rgold...@suse.com> A failure to lock i_rwsem would mean there is I/O being performed by another thread. So, let's bail. Reviewed-by: Christoph Hellwig <h...@lst.de> Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> --- mm/filemap.c | 7 ++-

Re: [PATCH 6/8] nowait aio: ext4

On 04/04/2017 03:41 AM, Christoph Hellwig wrote: > On Tue, Apr 04, 2017 at 09:58:53AM +0200, Jan Kara wrote: >> FS_NOWAIT looks a bit too generic given these are filesystem feature flags. >> Can we call it FS_NOWAIT_IO? > > It's way to generic as it's a feature of the particular file_operations

[PATCH 6/9] nowait aio: ext4

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail for direct I/O: + i_rwsem is lockable + Writing beyond end of file (will trigger allocation) + Blocks are not allocated at the write location Signed-off-by: Goldwyn Rodrigues <rgold...

[PATCH 3/9] nowait aio: return if direct write will trigger writeback

From: Goldwyn Rodrigues <rgold...@suse.com> Find out if the write will trigger a wait due to writeback. If yes, return -EAGAIN. This introduces a new function filemap_range_has_page() which returns true if the file's mapping has a page within the range mentioned. Return -EINVAL for buffer

[PATCH 8/9] nowait aio: btrfs

From: Goldwyn Rodrigues <rgold...@suse.com> Return EAGAIN if any of the following checks fail + i_rwsem is not lockable + NODATACOW or PREALLOC is not set + Cannot nocow at the desired location + Writing beyond end of file which is not allocated Signed-off-by: Goldwyn Rodrigues

[PATCH 5/9] nowait aio: return on congested block device

From: Goldwyn Rodrigues <rgold...@suse.com> A new flag BIO_NOWAIT is introduced to identify bio's orignating from iocb with IOCB_NOWAIT. This flag indicates to return immediately if a request cannot be made instead of retrying. To facilitate this, QUEUE_FLAG_NOWAIT is set to devices

  1   2   3   >