[PATCH v3] btrfs: handle dynamically reappearing missing device

If the device is not present at the time of (-o degrade) mount, the mount context will create a dummy missing struct btrfs_device. Later this device may reappear after the FS is mounted and then device is included in the device list but it missed the open_device part. So this patch handles that

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote: > On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote: > > From: Jeff Layton > > > > Add a documentation blob that explains what the i_version field is, how > > it is expected to work, and how it is currently

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote: > From: Jeff Layton > > Add a documentation blob that explains what the i_version field is, how > it is expected to work, and how it is currently implemented by various > filesystems. > > We already have

Unexpected raid1 behaviour

Could someone please point me towards some read about how btrfs handles multiple devices? Namely, kicking faulty devices and re-adding them. I've been using btrfs on single devices for a while, but now I want to start using it in raid1 mode. I booted into an Ubuntu 17.10 LiveCD and tried to see

Re: [PATCH v2 05/19] afs: convert to new i_version API

On Sat, 2017-12-16 at 11:18 -0500, Jeffrey Altman wrote: > Hi Jeff, > > A few thoughts on AFS usage below which might impact a future revision > of the API. I hope they are useful. > > On 12/16/2017 8:49 AM, Jeff Layton wrote: > > On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote: > > >

Re: [PATCH v2 05/19] afs: convert to new i_version API

Hi Jeff, A few thoughts on AFS usage below which might impact a future revision of the API. I hope they are useful. On 12/16/2017 8:49 AM, Jeff Layton wrote: > On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote: >> From: Jeff Layton >> >> For AFS, it's generally treated

How to repair errors only found with check --mode=lowmem

The following shows that errors are found with check --mode=lowmem, but are not picked up without lowmem. How would I go about fixing errors only reported by lowmem? [manjaro manjaro]# btrfs check --mode=lowmem --progress /dev/mapper/vg_svelte-home

[PATCH v2 01/19] fs: new API for handling inode->i_version

From: Jeff Layton Add a documentation blob that explains what the i_version field is, how it is expected to work, and how it is currently implemented by various filesystems. We already have inode_inc_iversion. Add several other functions for manipulating and accessing the

[PATCH v2 03/19] fat: convert to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/fat/dir.c | 2 +- fs/fat/inode.c | 8 fs/fat/namei_msdos.c | 6 +++--- fs/fat/namei_vfat.c | 20 ++-- 4 files changed, 18 insertions(+), 18 deletions(-) diff

[PATCH v2 02/19] fs: don't take the i_lock in inode_inc_iversion

From: Jeff Layton The rationale for taking the i_lock when incrementing this value is lost in antiquity. The readers of the field don't take it (at least not universally), so my assumption is that it was only done here to serialize incrementors. If that is indeed the case,

[PATCH v2 05/19] afs: convert to new i_version API

From: Jeff Layton For AFS, it's generally treated as an opaque value, so we use the *_raw variants of the API here. Note that AFS has quite a different definition for this counter. AFS only increments it on changes to the data, not for the metadata. We'll need to reconcile

[PATCH v2 04/19] affs: convert to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/affs/amigaffs.c | 4 ++-- fs/affs/dir.c | 4 ++-- fs/affs/super.c| 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c index

[PATCH v2 07/19] exofs: switch to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/exofs/dir.c | 8 fs/exofs/super.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c index 98233a97b7b8..36e314083b80 100644 ---

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

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/btrfs/delayed-inode.c | 6 -- fs/btrfs/inode.c | 6 -- fs/btrfs/tree-log.c | 3 ++- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/delayed-inode.c

[PATCH v2 09/19] ext4: convert to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton Acked-by: Theodore Ts'o --- fs/ext4/dir.c| 8 fs/ext4/inline.c | 6 +++--- fs/ext4/inode.c | 12 fs/ext4/ioctl.c | 2 +- fs/ext4/namei.c | 4 ++--

[PATCH v2 10/19] nfs: convert to new i_version API

From: Jeff Layton For NFS, we just use the "raw" API since the i_version is mostly managed by the server. The exception there is when the client holds a write delegation, but we only need to bump it once there anyway to handle CB_GETATTR. Signed-off-by: Jeff Layton

[PATCH v2 11/19] nfsd: convert to new i_version API

From: Jeff Layton Mostly just making sure we use the "get" wrappers so we know when it is being fetched for later use. Signed-off-by: Jeff Layton --- fs/nfsd/nfsfh.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfsd/nfsfh.h

Re: [PATCH v2 05/19] afs: convert to new i_version API

On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote: > From: Jeff Layton > > For AFS, it's generally treated as an opaque value, so we use the > *_raw variants of the API here. > > Note that AFS has quite a different definition for this counter. AFS > only increments it on

[PATCH v2 13/19] ufs: use new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/ufs/dir.c | 8 fs/ufs/inode.c | 2 +- fs/ufs/super.c | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c index 2edc1755b7c5..547c4d4c4db8 100644

[PATCH v2 14/19] xfs: convert to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/xfs/libxfs/xfs_inode_buf.c | 5 +++-- fs/xfs/xfs_icache.c | 4 ++-- fs/xfs/xfs_inode.c| 2 +- fs/xfs/xfs_inode_item.c | 2 +- fs/xfs/xfs_trans_inode.c | 2 +- 5 files

[PATCH v2 15/19] IMA: switch IMA over to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- security/integrity/ima/ima_api.c | 2 +- security/integrity/ima/ima_main.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/security/integrity/ima/ima_api.c

[PATCH v2 16/19] fs: only set S_VERSION when updating times if necessary

From: Jeff Layton We only really need to update i_version if someone has queried for it since we last incremented it. By doing that, we can avoid having to update the inode if the times haven't changed. If the times have changed, then we go ahead and forcibly increment the

[PATCH v2 12/19] ocfs2: convert to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/ocfs2/dir.c | 14 +++--- fs/ocfs2/inode.c| 2 +- fs/ocfs2/namei.c| 2 +- fs/ocfs2/quota_global.c | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) diff

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

From: Jeff Layton Since i_version is mostly treated as an opaque value, we can exploit that fact to avoid incrementing it when no one is watching. With that change, we can avoid incrementing the counter on writes, unless someone has queried for it since it was last

[PATCH v2 17/19] xfs: avoid setting XFS_ILOG_CORE if i_version doesn't need incrementing

From: Jeff Layton If XFS_ILOG_CORE is already set then go ahead and increment it. Signed-off-by: Jeff Layton --- fs/xfs/xfs_trans_inode.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/fs/xfs/xfs_trans_inode.c

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

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 dirty if that actually occurred or if one of the times was updated.

[PATCH v2 08/19] ext2: convert to new i_version API

From: Jeff Layton Signed-off-by: Jeff Layton --- fs/ext2/dir.c | 8 fs/ext2/super.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c index 987647986f47..c99f14fec3f3 100644 ---

[PATCH v2 00/19] fs: rework and optimize i_version handling in filesystems

From: Jeff Layton v2: - xfs should use inode_peek_iversion instead of inode_peek_iversion_raw - rework file_update_time patch - don't dirty inode when only S_ATIME is set and SB_LAZYTIME is enabled - better comments and documentation tl;dr: I think we can greatly reduce the

[PATCH 2/7] 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

[PATCHSET v3] blk-mq: reimplement timeout handling

Hello, Changes from [v2] - Possible extended looping around seqcount and u64_stat_sync fixed. - Misplaced MQ_RQ_IDLE state setting fixed. - RQF_MQ_TIMEOUT_EXPIRED added to prevent firing the same timeout multiple times. - s/queue_rq_src/srcu/ patch added. - Other misc changes. Changes

[PATCH 1/7] 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 ---

[PATCH 5/7] 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 3/7] 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/7] 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 | 22

[PATCH 4/7] 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 6/7] 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.

Re: [PATCH v5 77/78] irqdomain: Convert to XArray

On Fri, 15 Dec 2017 22:04:49 +, Matthew Wilcox wrote: > > From: Matthew Wilcox > > In a non-critical path, irqdomain wants to know how many entries are > stored in the xarray, so add xa_count(). This is a pretty straightforward > conversion; mostly just removing

Re: [4.14.3] btrfs out of space error

On Sat, Dec 16, 2017 at 12:07 AM, Hans van Kranenburg wrote: > On 12/15/2017 09:53 AM, Qu Wenruo wrote: >> On 2017年12月15日 16:36, Ian Kumlien wrote: >>> On Fri, Dec 15, 2017 at 6:34 AM, Roman Mamedov wrote: On Fri, 15 Dec 2017 01:39:03 +0100

Re: [4.14.3] btrfs out of space error

On Fri, Dec 15, 2017 at 9:53 AM, Qu Wenruo wrote: > On 2017年12月15日 16:36, Ian Kumlien wrote: >> On Fri, Dec 15, 2017 at 6:34 AM, Roman Mamedov wrote: >>> On Fri, 15 Dec 2017 01:39:03 +0100 >>> Ian Kumlien wrote: >>> Hi,

Re: [4.14.3] btrfs out of space error

On Fri, Dec 15, 2017 at 5:01 AM, Chris Murphy wrote: > On Thu, Dec 14, 2017 at 5:39 PM, Ian Kumlien wrote: >> Hi, >> >> Running a 4.14.3 kernel, this just happened, but there should have >> been another 20 gigs or so available. >> >> The filesystem