[PATCH 2/3 v2] btrfs-progs: check: do not reset ret after try_repair_inode

If repair is enabled and try_repair_inode() failed in check_inode_recs(), then value @ret will be reset to 0 anyway. Then counter @error won't be incremented. In other words, if previous check of the root directory is fine, check_inode_recs() always returns 0 even it failed to repair inodes. So

[PATCH] Re: [Bug-tar] Detection of sparse files is broken on btrfs

On Monday, January 8, 2018 3:29:17 AM CET Mark H Weaver wrote: > I propose that we revisit this bug and fix it. We clearly cannot assume that > st_blocks == 0 implies that the file contains only zeroes. . only on btrfs, as far as we know, because of some race condition. So what about special

Re: [PATCH v2 06/17] btrfs-progs: lowmem check: introduce force_cow_in_new_chunk()

On 2017年12月27日 09:11, Su Yue wrote: > > [snip] Manually allocation in advance has its advantage, like we can determine if there is enough space for new chunk instead of checking every return value with ENOSPC. However in current case, your metadata usage is

Re: [PATCH 3/3] btrfs-progs: check: record last checked root_item in original mode

On 01/09/2018 03:03 AM, David Sterba wrote: On Tue, Nov 21, 2017 at 06:15:24PM +0800, Su Yue wrote: check_fs_roots() will check all fs trees again if fs_info->tree_root have been cowed. It is inefficient if there are many subvolumes in filesystem. And it also causes dead loop while repairing

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 01/08/2018 08:15 PM, Tejun Heo wrote: > Currently, blk-mq protects only the issue path with RCU. This patch > puts the completion path under the same RCU protection. This will be > used to synchronize issue/completion against timeout by later patches, > which will also add the comments. > >

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

Hi tejun Many thanks for your kindly response. On 01/09/2018 11:37 AM, Tejun Heo wrote: > Hello, > > On Tue, Jan 09, 2018 at 11:08:04AM +0800, jianchao.wang wrote: >>> But what'd prevent the completion reinitializing the request and then >>> the actual completion path coming in and completing

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

Hello, On Tue, Jan 09, 2018 at 11:08:04AM +0800, jianchao.wang wrote: > > But what'd prevent the completion reinitializing the request and then > > the actual completion path coming in and completing the request again? > > blk_mark_rq_complete() will gate and ensure there will be only one >

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

Hi tejun Many thanks for you kindly response. On 01/09/2018 01:27 AM, Tejun Heo wrote: > Hello, Jianchao. > > On Fri, Dec 22, 2017 at 12:02:20PM +0800, jianchao.wang wrote: >>> On Thu, Dec 21, 2017 at 11:56:49AM +0800, jianchao.wang wrote: It's worrying that even though the

[PATCH V4 0/3] Add missing flags in the kernel

(added reroll count in the $subject) v3->v4: Patch reordered. Add BTRFS_SUPER_FLAG_METADUMP_V2 to BTRFS_SUPER_FLAG_SUPP v2->v3: Modify BTRFS_SUPER_FLAG_SUPP so that it would fail instead of warn. v1->v2: Fail to mount if BTRFS_SUPER_FLAG_CHANGING_FSID is set. Following bits are already used

Re: [PATCH v2 1/2] btrfs-progs: Merge btrfs_alloc_data_chunk into btrfs_alloc_chunk

On 01/08/2018 04:25 PM, Qu Wenruo wrote: We used to have two chunk allocators, btrfs_alloc_chunk() and btrfs_alloc_data_chunk(), the former is the more generic one, while the later is only used in mkfs and convert, to allocate SINGLE data chunk. Although btrfs_alloc_data_chunk() has some

Re: [RFC PATCH bpf-next v2 0/4] Separate error injection table from kprobes

On Thu, 4 Jan 2018 11:07:16 -0500 Josef Bacik wrote: > On Tue, Dec 26, 2017 at 04:46:28PM +0900, Masami Hiramatsu wrote: > > Hi Josef and Alexei, > > > > Here are the 2nd version of patches to moving error injection > > table from kprobes. In this series I did a small

[PATCH 2/3] btrfs: add support for SUPER_FLAG_CHANGING_FSID in btrfs.ko

Userland sets SUPER_FLAG_CHANGING_FSID and resets it only when changing fsid is complete. Its not a good idea to mount the device anything in between. This patch doesn't add SUPER_FLAG_CHANGING_FSID into BTRFS_SUPER_FLAG_SUPP list, so mount would fail (along with the fix in the next patch) when

[PATCH 1/3] btrfs: define SUPER_FLAG_METADUMP_V2

btrfs-progs uses super flag bit BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34). So just define that in kernel so that we know its been used. Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 3 ++- include/uapi/linux/btrfs_tree.h | 1 + 2 files changed, 3

[PATCH 0/3] Add missing flags in the kernel.

v3->v4: Patch reordered. Add BTRFS_SUPER_FLAG_METADUMP_V2 to BTRFS_SUPER_FLAG_SUPP v2->v3: Modify BTRFS_SUPER_FLAG_SUPP so that it would fail instead of warn. v1->v2: Fail to mount if BTRFS_SUPER_FLAG_CHANGING_FSID is set. Following bits are already used in user land, so bring it to the kernel

[PATCH 3/3] btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP

It appear from the original commit [1] that there isn't any design specific reason not to fail the mount instead of just warning. This patch will change it to fail. [1] commit 319e4d0661e5323c9f9945f0f8fb5905e5fe74c3 btrfs: Enhance super validation check Signed-off-by: Anand Jain

Re: [PATCH] generic/015: Change the test filesystem size to 101mb

On 2018年01月08日 21:55, Timofey Titovets wrote: > 2018-01-08 15:54 GMT+03:00 Qu Wenruo : >> >> >> On 2018年01月08日 16:43, Nikolay Borisov wrote: >>> This test has been failing for btrfs for quite some time, >>> at least since 4.7. There are 2 implementation details of btrfs

Re: [PATCH 2/2] btrfs-progs: misc-test: Add test case to check if fi usage and show report consistent unallocated space

On 2018年01月09日 03:39, David Sterba wrote: > On Tue, Jan 02, 2018 at 02:33:15PM +0800, Qu Wenruo wrote: >> Signed-off-by: Qu Wenruo >> --- >> tests/misc-tests/028-fi-usage-cross-check/test.sh | 46 >> +++ >> 1 file changed, 46 insertions(+) >> create mode

Re: [PATCH 8/8] blk-mq: rename blk_mq_hw_ctx->queue_rq_srcu to ->srcu

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > The RCU protection has been expanded to cover both queueing and > completion paths making ->queue_rq_srcu a misnomer. Rename it to > ->srcu as suggested by Bart. Reviewed-by: Bart Van Assche

Re: [PATCH 7/8] blk-mq: remove REQ_ATOM_STARTED

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > After the recent updates to use generation number and state based > synchronization, we can easily replace REQ_ATOM_STARTED usages by > adding an extra state to distinguish completed but not yet freed > state. > > Add MQ_RQ_COMPLETE and

Re: [PATCH 6/8] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > After the recent updates to use generation number and state based > synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE except > to avoid firing the same timeout multiple times. > > Remove all REQ_ATOM_COMPLETE usages and use a new

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 01/09/18 00:27, Holger Hoffstätte wrote: > On 01/08/18 23:55, Jens Axboe wrote: >> the good old >> >> int srcu_idx = srcu_idx; >> >> should get the job done. > > (Narrator: It didn't.) Narrator: we retract our previous statement and apologize for the confusion. It works fine when you

Re: [PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > @@ -230,6 +232,27 @@ struct request { > > unsigned short write_hint; > > + /* > + * On blk-mq, the lower bits of ->gstate carry the MQ_RQ_* state > + * value and the upper bits the generation number which is > + *

[PATCH][btrfs-next] Btrfs: extent map selftest: add missing void parameter to btrfs_test_extent_map

From: Colin Ian King Add a missing void parameter to function btrfs_test_extent_map, fixes sparse warning: warning: non-ANSI function declaration of function 'btrfs_test_extent_map' Signed-off-by: Colin Ian King ---

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 1/8/18 1:15 PM, Jens Axboe wrote: > On 1/8/18 12:57 PM, Holger Hoffstätte wrote: >> On 01/08/18 20:15, Tejun Heo wrote: >>> Currently, blk-mq protects only the issue path with RCU. This patch >>> puts the completion path under the same RCU protection. This will be >>> used to synchronize

btrfs scrub not repair corruption

Greetings, I'm running btrfs scrub on my raid each week (is that too often?) and I'm having a problem that it reports corruption, says it's repaired but next week reports it again. Here is from dmesg: $ cat btrfs_error_2017_12_18 [390739.538838] BTRFS warning (device dm-13): checksum error at

Re: Recommendations for balancing as part of regular maintenance?

On Mon, Jan 08, 2018 at 04:43:02PM -0500, Tom Worster wrote: > On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: > > >On 2018-01-08 11:20, ein wrote: > > > >> On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: > >> > >> > [...] > >> > > >> > And here's the FAQ entry: > >> > > >> > Q: Do I need

Re: [PATCH 5/8] blk-mq: make blk_abort_request() trigger timeout path

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > @@ -156,12 +156,12 @@ void blk_timeout_work(struct work_struct *work) > */ > void blk_abort_request(struct request *req) > { > - if (blk_mark_rq_complete(req)) > - return; > - > if (req->q->mq_ops) { > -

Re: [PATCH 4/8] blk-mq: use blk_mq_rq_state() instead of testing REQ_ATOM_COMPLETE

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > blk_mq_check_inflight() and blk_mq_poll_hybrid_sleep() test > REQ_ATOM_COMPLETE to determine the request state. Both uses are > speculative and we can test REQ_ATOM_STARTED and blk_mq_rq_state() for > equivalent results. Replace the tests.

Re: Recommendations for balancing as part of regular maintenance?

On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: On 2018-01-08 11:20, ein wrote: > On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: > > > [...] > > > > And here's the FAQ entry: > > > > Q: Do I need to run a balance regularly? > > > > A: In general usage, no. A full unfiltered balance

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Mon, 2018-01-08 at 21:17 +0100, Krzysztof Kozlowski wrote: > On Mon, Jan 08, 2018 at 02:15:29PM -0500, Jeff Layton wrote: > > On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote: > > > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote: > > > > On Mon, 2018-01-08 at 18:29

Re: [PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > +static void blk_mq_rq_update_aborted_gstate(struct request *rq, u64 gstate) > +{ > + unsigned long flags; > + > + local_irq_save(flags); > + u64_stats_update_begin(>aborted_gstate_sync); > + rq->aborted_gstate = gstate; > +

Re: Recommendations for balancing as part of regular maintenance?

On 08.01.2018 19:34 Austin S. Hemmelgarn wrote: > On 2018-01-08 13:17, Graham Cobb wrote: >> On 08/01/18 16:34, Austin S. Hemmelgarn wrote: >>> Ideally, I think it should be as generic as reasonably possible, >>> possibly something along the lines of: >>> >>> A: While not strictly necessary,

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Mon, Jan 08, 2018 at 02:15:29PM -0500, Jeff Layton wrote: > On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote: > > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote: > > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote: > > > > (...) > > > > > > > Ok,

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 1/8/18 12:57 PM, Holger Hoffstätte wrote: > On 01/08/18 20:15, Tejun Heo wrote: >> Currently, blk-mq protects only the issue path with RCU. This patch >> puts the completion path under the same RCU protection. This will be >> used to synchronize issue/completion against timeout by later

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Mon, 2018-01-08 at 14:15 -0500, Jeff Layton wrote: > On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote: > > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote: > > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote: > > > > (...) > > > > > > > Ok, thanks. If

Re: [PATCH v2 00/10] bugfixes and regression tests of btrfs_get_extent

On Fri, Jan 05, 2018 at 12:51:07PM -0700, Liu Bo wrote: > Although > commit e6c4efd87ab0 ("btrfs: Fix and enhance merge_extent_mapping() to insert > best fitted extent map") > fixed up the negetive em->len, it has introduced several regressions, several > has been fixed by > > commit

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

On 01/08/18 20:15, Tejun Heo wrote: > Currently, blk-mq protects only the issue path with RCU. This patch > puts the completion path under the same RCU protection. This will be > used to synchronize issue/completion against timeout by later patches, > which will also add the comments. > >

Re: [PATCH 2/3] btrfs: define SUPER_FLAG_METADUMP_V2

On Mon, Jan 08, 2018 at 04:20:58PM +0800, Qu Wenruo wrote: > > > On 2018年01月08日 16:04, Anand Jain wrote: > > btrfs-progs uses super flag bit BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34). > > So just define that in kernel so that we know its been used. This patch > > does not add it to

Re: [PATCH 2/2] btrfs-progs: misc-test: Add test case to check if fi usage and show report consistent unallocated space

On Tue, Jan 02, 2018 at 02:33:15PM +0800, Qu Wenruo wrote: > Signed-off-by: Qu Wenruo > --- > tests/misc-tests/028-fi-usage-cross-check/test.sh | 46 > +++ > 1 file changed, 46 insertions(+) > create mode 100755

Re: [PATCH] bytrfs-progs: Print error on invalid extent item format during check

On Fri, Dec 29, 2017 at 11:01:44AM +0200, Nikolay Borisov wrote: > While performing normal mode check if the code comes across an invalid > extent format it will just BUG() and exit without printing any useful > information for debugging. Improve the situation by outputting the > key/leaf

Re: [PATCH 1/8] blk-mq: move hctx lock/unlock into a helper

On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote: > +static void hctx_unlock(struct blk_mq_hw_ctx *hctx, int srcu_idx) > +{ > + if (!(hctx->flags & BLK_MQ_F_BLOCKING)) > + rcu_read_unlock(); > + else > + srcu_read_unlock(hctx->queue_rq_srcu, srcu_idx); > +} > + >

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote: > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote: > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote: > > (...) > > > > > Ok, thanks. If you're seeing hangs then that might imply that we have > > > > some

[PATCH 1/8] blk-mq: move hctx lock/unlock into a helper

From: Jens Axboe Move the RCU vs SRCU logic into lock/unlock helpers, which makes the actual functional bits within the locked region much easier to read. tj: Reordered in front of timeout revamp patches and added the missing blk_mq_run_hw_queue() conversion.

[PATCH 3/8] blk-mq: replace timeout synchronization with a RCU and generation based scheme

Currently, blk-mq timeout path synchronizes against the usual issue/completion path using a complex scheme involving atomic bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence rules. Unfortunately, it contains quite a few holes. There's a complex dancing around REQ_ATOM_STARTED and

[PATCH 2/8] blk-mq: protect completion path with RCU

Currently, blk-mq protects only the issue path with RCU. This patch puts the completion path under the same RCU protection. This will be used to synchronize issue/completion against timeout by later patches, which will also add the comments. Signed-off-by: Tejun Heo ---

[PATCHSET v4] blk-mq: reimplement timeout handling

Hello, Changes from [v3] - Rebased on top of for-4.16/block. - Integrated Jens's hctx_[un]lock() factoring patch and refreshed the patches accordingly. - Added comment explaining the use of hctx_lock() instead of rcu_read_lock() in completion path. Changes from [v2] - Possible extended

[PATCH 5/8] blk-mq: make blk_abort_request() trigger timeout path

With issue/complete and timeout paths now using the generation number and state based synchronization, blk_abort_request() is the only one which depends on REQ_ATOM_COMPLETE for arbitrating completion. There's no reason for blk_abort_request() to be a completely separate path. This patch makes

[PATCH 4/8] blk-mq: use blk_mq_rq_state() instead of testing REQ_ATOM_COMPLETE

blk_mq_check_inflight() and blk_mq_poll_hybrid_sleep() test REQ_ATOM_COMPLETE to determine the request state. Both uses are speculative and we can test REQ_ATOM_STARTED and blk_mq_rq_state() for equivalent results. Replace the tests. This will allow removing REQ_ATOM_COMPLETE usages from

[PATCH 7/8] blk-mq: remove REQ_ATOM_STARTED

After the recent updates to use generation number and state based synchronization, we can easily replace REQ_ATOM_STARTED usages by adding an extra state to distinguish completed but not yet freed state. Add MQ_RQ_COMPLETE and replace REQ_ATOM_STARTED usages with blk_mq_rq_state() tests.

[PATCH 6/8] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

After the recent updates to use generation number and state based synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE except to avoid firing the same timeout multiple times. Remove all REQ_ATOM_COMPLETE usages and use a new rq_flags flag RQF_MQ_TIMEOUT_EXPIRED to avoid firing the same

[PATCH 8/8] blk-mq: rename blk_mq_hw_ctx->queue_rq_srcu to ->srcu

The RCU protection has been expanded to cover both queueing and completion paths making ->queue_rq_srcu a misnomer. Rename it to ->srcu as suggested by Bart. Signed-off-by: Tejun Heo Cc: Bart Van Assche --- block/blk-mq.c | 14 +++---

Re: [PATCH 3/3] btrfs-progs: check: record last checked root_item in original mode

On Tue, Nov 21, 2017 at 06:15:24PM +0800, Su Yue wrote: > check_fs_roots() will check all fs trees again if fs_info->tree_root > have been cowed. > It is inefficient if there are many subvolumes in filesystem. > > And it also causes dead loop while repairing > fuzz-tests/images/bko-161811.raw: >

Re: [PATCH 2/3] btrfs-progs: check: do not reset ret after try_repair_inode

On Tue, Nov 21, 2017 at 06:15:23PM +0800, Su Yue wrote: > After failure of try_repair_inode(), the value @ret will be reseted > anyway. Then counter @error won't be incremented. Can you pleae expand the changelog? I don't see how this patch helps, the extra line does not hurt readability so I

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote: > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote: (...) > > > Ok, thanks. If you're seeing hangs then that might imply that we have > > > some sort of excessive looping going on in the cmpxchg loops. > > > > > > Could

Re: Recommendations for balancing as part of regular maintenance?

On 2018-01-08 13:17, Graham Cobb wrote: On 08/01/18 16:34, Austin S. Hemmelgarn wrote: Ideally, I think it should be as generic as reasonably possible, possibly something along the lines of: A: While not strictly necessary, running regular filtered balances (for example `btrfs balance start

Re: [PATCH 1/2] btrfs-progs: Remove unused parameter trans

On Tue, Oct 31, 2017 at 05:23:03PM +0800, Gu Jinxiang wrote: > Some parameter of trans is not used indeed. > Let's remove them. > > Signed-off-by: Gu Jinxiang 1 and 2 applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: [PATCH 1/2] btrfs-progs: qgroup: move btrfs_show_qgroups's error handler to __qgroup_search

On Mon, Nov 13, 2017 at 01:33:15PM +0800, Lu Fengqi wrote: > We have to process the return value of BTRFS_IOC_TREE_SEARCH ioctl in > advance, so that we can distinguish between the two case where quota > is not enabled (ioctl return -ENOENT) and either parent qgroup or child > qgroup does not

Re: Recommendations for balancing as part of regular maintenance?

On 08/01/18 16:34, Austin S. Hemmelgarn wrote: > Ideally, I think it should be as generic as reasonably possible, > possibly something along the lines of: > > A: While not strictly necessary, running regular filtered balances (for > example `btrfs balance start -dusage=50 -dlimit=2 -musage=50

Re: [PATCH v4 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed

On Fri, Dec 22, 2017 at 07:05:55AM -0500, Jeff Layton wrote: > From: Jeff Layton > > At this point, we know that "now" and the file times may differ, and we > suspect that the i_version has been flagged to be bumped. Attempt to > bump the i_version, and only mark the inode

Re: [PATCH v4 06/19] btrfs: convert to new i_version API

On Fri, Dec 22, 2017 at 07:05:43AM -0500, Jeff Layton wrote: > From: Jeff Layton > > Signed-off-by: Jeff Layton Acked-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message

Re: [PATCH v4 18/19] btrfs: only dirty the inode in btrfs_update_time if something was changed

On Wed, Jan 03, 2018 at 11:43:51AM -0500, Jeff Layton wrote: > I posted this set just before xmas, and am hoping to send Linus a PR for > it when the next merge window opens. Both the ext4 and xfs folks have > acked their respective parts. > > I'll note that this set helps small I/O workloads on

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

gt; > > i_version API > > > > > git bisect good 325a1de4a691512a48c1426b943a7b0b9f8d6744 > > > > > # good: [a94fe10fb114c169e7ddaecd8251521886409121] checkpatch: add > > > > > pF/pf deprecation warning > > > > > git bisect good a94fe1

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

d1184fdcd63299a5fee59ac000f2067 > > > > # bad: [448f8c749a7a0ae03505823910ec45a112678048] Merge > > > > remote-tracking branch 'iversion/iversion-next' > > > > git bisect bad 448f8c749a7a0ae03505823910ec45a112678048 > > > > # bad: [8618bff776758ebff5b55211e7b5a60a0f

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

Hello, Jianchao. On Fri, Dec 22, 2017 at 12:02:20PM +0800, jianchao.wang wrote: > > On Thu, Dec 21, 2017 at 11:56:49AM +0800, jianchao.wang wrote: > >> It's worrying that even though the blk_mark_rq_complete() here is > >> intended to synchronize with timeout path, but it indeed give the > >>

Re: [PATCH 0/2] btrfs-progs: Fix progs_extra build failures

On Sat, Dec 23, 2017 at 09:52:36PM +0100, Hans van Kranenburg wrote: > Alternatively, it might be a better idea to just remove the deprecated source > files, since this is not the first time build failures in them went unnoticed. btrfs-show-super and btrfs-calc-size have been deprecated since

Re: [PATCH 1/7] blk-mq: protect completion path with RCU

Hello, Christoph. On Fri, Dec 29, 2017 at 02:04:18AM -0800, Christoph Hellwig wrote: > Why do you need the srcu protection? The completion path can never > sleep. > > If there is a good reason to keep it please add commment, and > make the srcu variant a separate function only used by drivers

Re: [PATCHSET v3] blk-mq: reimplement timeout handling

On Fri, Dec 29, 2017 at 02:02:39AM -0800, Christoph Hellwig wrote: > This seems to miss the linux-block list once again. Please include > it in the next resend. Sorry about that. Copy/pasted from the older thread without thinking. Thanks. -- tejun -- To unsubscribe from this list: send the

Re: Recommendations for balancing as part of regular maintenance?

On 2018-01-08 11:20, ein wrote: On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: [...] And here's the FAQ entry: Q: Do I need to run a balance regularly? A: In general usage, no. A full unfiltered balance typically takes a long time, and will rewrite huge amounts of data unnecessarily.

Re: Recommendations for balancing as part of regular maintenance?

On 01/08/2018 04:55 PM, Austin S. Hemmelgarn wrote: > [...] > > And here's the FAQ entry: > > Q: Do I need to run a balance regularly? > > A: In general usage, no. A full unfiltered balance typically takes a > long time, and will rewrite huge amounts of data unnecessarily. You may > wish to run

Recommendations for balancing as part of regular maintenance?

So, for a while now I've been recommending small filtered balances to people as part of regular maintenance for BTRFS filesystems under the logic that it does help in some cases and can't really hurt (and if done right, is really inexpensive in terms of resources). This ended up integrated

Next btrfs development cycle open - 4.17

Hi, a friendly reminder of the timetable and what's expected at this phase. 4.14 - current 4.15 - upcoming, urgent regression fixes only 4.16 - development closed, pull request in prep, fixes or regressions only 4.17 - development open, until 4.16-rc5 (at least)

Re: [PATCH] generic/015: Change the test filesystem size to 101mb

On 8.01.2018 14:54, Qu Wenruo wrote: > > > On 2018年01月08日 16:43, Nikolay Borisov wrote: >> This test has been failing for btrfs for quite some time, >> at least since 4.7. There are 2 implementation details of btrfs that >> it exposes: >> >> 1. Currently btrfs filesystem under 100mb are

Re: [PATCH] generic/015: Change the test filesystem size to 101mb

2018-01-08 15:54 GMT+03:00 Qu Wenruo : > > > On 2018年01月08日 16:43, Nikolay Borisov wrote: >> This test has been failing for btrfs for quite some time, >> at least since 4.7. There are 2 implementation details of btrfs that >> it exposes: >> >> 1. Currently btrfs filesystem

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Mon, 2018-01-08 at 05:30 -0800, Matthew Wilcox wrote: > On Fri, Dec 22, 2017 at 07:05:56AM -0500, Jeff Layton wrote: > > + cur = inode_peek_iversion_raw(inode); > > + for (;;) { > > + /* If flag is clear then we needn't do anything */ > > + if (!force && !(cur &

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

5b55211e7b5a60a0fc119a5] fs: > > > handle inode->i_version more efficiently > > > > That's really strange. I'm afraid I have no idea what could be going on. > > > > With NFS, we really just treat i_version as an opaque value, so I'm not > > sure

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Fri, Dec 22, 2017 at 07:05:56AM -0500, Jeff Layton wrote: > + cur = inode_peek_iversion_raw(inode); > + for (;;) { > + /* If flag is clear then we needn't do anything */ > + if (!force && !(cur & I_VERSION_QUERIED)) > + return false; > +

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On Sun, 7 Jan 2018 19:01:57 -0800 Alexei Starovoitov wrote: > On 12/29/17 12:20 AM, Masami Hiramatsu wrote: > >> Please run Josef's test in the !ftrace setup. > > Yes, I'll add the result of the test case. > > if Josef's test is passing in !ftrace config, > please resend your

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

lt except: [nfsd] vers2=n vers3=n The client logs for nfsroot mounts are: Jan 08 14:07:25 :: running hook [net_nfs4] Jan 08 14:07:25 IP-Config: eth0 hardware address ba:17:70:7e:87:d1 mtu 1500 Jan 08 14:07:25 IP-Config: eth0 guessed broadcast address 192.168.1.255 Jan 08 14:07:25 IP-Config: et

Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently

On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote: > On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton wrote: > > From: Jeff Layton > > > > Since i_version is mostly treated as an opaque value, we can exploit that > > fact to avoid incrementing it

Re: [PATCH] generic/015: Change the test filesystem size to 101mb

On 2018年01月08日 16:43, Nikolay Borisov wrote: > This test has been failing for btrfs for quite some time, > at least since 4.7. There are 2 implementation details of btrfs that > it exposes: > > 1. Currently btrfs filesystem under 100mb are created in Mixed block > group mode. Freespace

Re: [PATCH 0/2] Remove custom crc32c init code from btrfs

On 8.01.2018 12:21, Timofey Titovets wrote: > 2018-01-08 12:45 GMT+03:00 Nikolay Borisov : >> So here is a small 2 patch set which removes btrfs' manual initialisation of >> the lower level crc32c module. Explanation why is ok can be found in Patch >> 2/2. >> >> Patch 1/2

[PATCH] btrfs: use correct string length

From: Xiongfeng Wang gcc-8 reports fs/btrfs/ioctl.c: In function 'btrfs_ioctl': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 1024 equals destination size [-Wstringop-truncation] We need one less byte or call strlcpy() to make it a

Re: [PATCH 0/2] Remove custom crc32c init code from btrfs

2018-01-08 12:45 GMT+03:00 Nikolay Borisov : > So here is a small 2 patch set which removes btrfs' manual initialisation of > the lower level crc32c module. Explanation why is ok can be found in Patch > 2/2. > > Patch 1/2 just adds a function to the generic crc32c header which

[PATCH 0/2] Remove custom crc32c init code from btrfs

So here is a small 2 patch set which removes btrfs' manual initialisation of the lower level crc32c module. Explanation why is ok can be found in Patch 2/2. Patch 1/2 just adds a function to the generic crc32c header which allows querying the actual crc32c implementaiton used (i.e. software or

[PATCH 2/2] btrfs: Remove custom crc32c init code

The custom crc32 init code was introduced in 14a958e678cd ("Btrfs: fix btrfs boot when compiled as built-in") to enable using btrfs as a built-in. However, later as pointed out by 60efa5eb2e88 ("Btrfs: use late_initcall instead of module_init") this wasn't enough and finally btrfs was switched to

[PATCH 1/2] libcrc32c: Add crc32c_impl function

This function returns a string with the currently in-use implementation of the crc32c algorithm, i.e crc32c-generic (for unoptimised, generic implementation) or crc32c-intel for the sse optimised version. This will be used by btrfs. Signed-off-by: Nikolay Borisov ---

Re: [PATCH 1/4] Btrfs: btrfs_dedupe_file_range() ioctl, remove 16MiB restriction

2017-12-20 0:23 GMT+03:00 Darrick J. Wong : > On Tue, Dec 19, 2017 at 01:02:44PM +0300, Timofey Titovets wrote: >> At now btrfs_dedupe_file_range() restricted to 16MiB range for >> limit locking time and memory requirement for dedup ioctl() >> >> For too big input range

[PATCH v2] btrfs: handle failure of add_pending_csums

add_pending_csums was added as part of the new data=ordered implementation in e6dcd2dc9c48 ("Btrfs: New data=ordered implementation"). Even back then it called the btrfs_csum_file_blocks which can fail but it never bothered handling the failure. In ENOMEM situation this could lead to the

[PATCH] generic/015: Change the test filesystem size to 101mb

This test has been failing for btrfs for quite some time, at least since 4.7. There are 2 implementation details of btrfs that it exposes: 1. Currently btrfs filesystem under 100mb are created in Mixed block group mode. Freespace accounting for it is not 100% accurate - I've observed around

[PATCH v2 1/2] btrfs-progs: Merge btrfs_alloc_data_chunk into btrfs_alloc_chunk

We used to have two chunk allocators, btrfs_alloc_chunk() and btrfs_alloc_data_chunk(), the former is the more generic one, while the later is only used in mkfs and convert, to allocate SINGLE data chunk. Although btrfs_alloc_data_chunk() has some special hacks to cooperate with convert, it's

Re: [PATCH 2/3] btrfs: define SUPER_FLAG_METADUMP_V2

On 2018年01月08日 16:04, Anand Jain wrote: > btrfs-progs uses super flag bit BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34). > So just define that in kernel so that we know its been used. This patch > does not add it to BTRFS_SUPER_FLAG_SUPP yet. > > Signed-off-by: Anand Jain >

Re: [PATCH 3/3] btrfs: add support for SUPER_FLAG_CHANGING_FSID in btrfs.ko

On 2018年01月08日 16:04, Anand Jain wrote: > Userland sets SUPER_FLAG_CHANGING_FSID and resets it only when changing > fsid is complete. Its not a good idea to mount the device anything in > between, so this patch fails the mount if SB SUPER_FLAG_CHANGING_FSID > is set. As we don't add

Re: [PATCH 1/3] btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP

On 2018年01月08日 16:04, Anand Jain wrote: > It appear from the original commit [1] that there isn't any design > specific reason not to fail the mount instead of just warning. This > patch will change it to fail. > > [1] > commit 319e4d0661e5323c9f9945f0f8fb5905e5fe74c3 > btrfs: Enhance

[PATCH 3/3] btrfs: add support for SUPER_FLAG_CHANGING_FSID in btrfs.ko

Userland sets SUPER_FLAG_CHANGING_FSID and resets it only when changing fsid is complete. Its not a good idea to mount the device anything in between, so this patch fails the mount if SB SUPER_FLAG_CHANGING_FSID is set. As we don't add SUPER_FLAG_CHANGING_FSID into BTRFS_SUPER_FLAG_SUPP list, so

[PATCH v3 0/3] Add missing flags in the kernel.

v2->v3: Modify BTRFS_SUPER_FLAG_SUPP so that it would fail instead of warn. v1->v2: Fail to mount if BTRFS_SUPER_FLAG_CHANGING_FSID is set. Following bits are already used in user land, so bring it to the kernel as well. #define BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34) #define

[PATCH 1/3] btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP

It appear from the original commit [1] that there isn't any design specific reason not to fail the mount instead of just warning. This patch will change it to fail. [1] commit 319e4d0661e5323c9f9945f0f8fb5905e5fe74c3 btrfs: Enhance super validation check Signed-off-by: Anand Jain

[PATCH 2/3] btrfs: define SUPER_FLAG_METADUMP_V2

btrfs-progs uses super flag bit BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34). So just define that in kernel so that we know its been used. This patch does not add it to BTRFS_SUPER_FLAG_SUPP yet. Signed-off-by: Anand Jain --- include/uapi/linux/btrfs_tree.h | 1 + 1 file