Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On Thu, Mar 2, 2017 at 6:48 PM, Chris Murphy wrote: > > Again, my data is fine. The problem I'm having is this: > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v4.10.1 > > Which says in the

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > tl;dr: I think we can greatly reduce the cost of the inode->i_version > counter, by exploiting the fact that we don't need to increment it > if no one is looking at it. We can also clean up the code to prepare > to eventually expose

[PATCH] Btrfs: add file item tracepoint

While debugging truncate problems, I found that these tracepoints could help us quickly know what went wrong. Two sets of tracepoints are created to track regular/prealloc file item and inline file item respectively, I put inline as a separate one since what inline file items cares about are way

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Sat, 2017-03-04 at 10:55 +1100, NeilBrown wrote: > On Wed, Dec 21 2016, Jeff Layton wrote: > > > We already have inode_inc_iversion. Add inode_set_iversion, > > inode_get_iversion, inode_cmp_iversion and inode_iversion_need_inc. > > This list of added interfaces is incomplete. > And some of

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Fri, 2017-03-03 at 18:00 -0500, J. Bruce Fields wrote: > On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > > tl;dr: I think we can greatly reduce the cost of the inode->i_version > > counter, by exploiting the fact that we don't need to increment it > > if no one is looking at it.

Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag

On Sat, 2017-03-04 at 11:03 +1100, NeilBrown wrote: > On Wed, Dec 21 2016, Jeff Layton wrote: > > > @@ -2072,7 +2093,12 @@ inode_cmp_iversion(const struct inode *inode, const > > u64 old) > > static inline bool > > inode_iversion_need_inc(struct inode *inode) > > { > > - return true; > > +

Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag

On Wed, Dec 21 2016, Jeff Layton wrote: > @@ -2072,7 +2093,12 @@ inode_cmp_iversion(const struct inode *inode, const > u64 old) > static inline bool > inode_iversion_need_inc(struct inode *inode) > { > - return true; > + bool ret; > + > + spin_lock(>i_lock); > + ret =

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Fri, 2017-03-03 at 17:36 -0500, J. Bruce Fields wrote: > The patch ordering is a little annoying as I'd like to be able to be > able to verify the implementation at the same time these new interfaces > are added, but, I don't know, I don't have a better idea. > Fair point. My thinking was

Re: [RFC PATCH v1 30/30] fs: convert i_version counter over to an atomic64_t

On Wed, Dec 21 2016, Jeff Layton wrote: > > +/* > + * We borrow the top bit in the i_version to use as a flag to tell us whether > + * it has been queried since we last bumped it. If it has, then we must bump > + * it and set the flag. Note that this means that we have to handle wrapping > + *

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Wed, Dec 21 2016, Jeff Layton wrote: > We already have inode_inc_iversion. Add inode_set_iversion, > inode_get_iversion, inode_cmp_iversion and inode_iversion_need_inc. This list of added interfaces is incomplete. And some of these interfaces could really use some justification up front. You

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

The patch ordering is a little annoying as I'd like to be able to be able to verify the implementation at the same time these new interfaces are added, but, I don't know, I don't have a better idea. Anyway, various nits: On Wed, Dec 21, 2016 at 12:03:28PM -0500, Jeff Layton wrote: > We already

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

Am Fri, 3 Mar 2017 07:19:06 -0500 schrieb "Austin S. Hemmelgarn" : > On 2017-03-03 00:56, Kai Krakow wrote: > > Am Thu, 2 Mar 2017 11:37:53 +0100 > > schrieb Adam Borowski : > > > >> On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote: >

Re: [PATCH] Btrfs: fix file corruption after cloning inline extents

On Fri, Mar 03, 2017 at 03:36:36PM +, Filipe Manana wrote: > On Fri, Mar 3, 2017 at 12:36 AM, Liu Bo wrote: > > On Thu, Mar 02, 2017 at 02:18:21PM -0800, Liu Bo wrote: > >> On Tue, Jul 14, 2015 at 04:34:48PM +0100, fdman...@kernel.org wrote: > >> > From: Filipe Manana

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

On Thu, Mar 02, 2017 at 06:04:33PM -0800, Liu Bo wrote: > On Thu, Mar 02, 2017 at 07:58:01AM -0800, Liu Bo wrote: > > On Wed, Mar 01, 2017 at 03:03:19PM -0500, Dave Jones wrote: > > > On Tue, Feb 28, 2017 at 05:12:01PM -0800, Liu Bo wrote: > > > > On Mon, Feb 27, 2017 at 11:23:42AM -0500,

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

On Fri, Mar 03, 2017 at 01:04:39PM -0500, Dave Jones wrote: > On Thu, Mar 02, 2017 at 06:04:33PM -0800, Liu Bo wrote: > > On Thu, Mar 02, 2017 at 07:58:01AM -0800, Liu Bo wrote: > > > On Wed, Mar 01, 2017 at 03:03:19PM -0500, Dave Jones wrote: > > > > On Tue, Feb 28, 2017 at 05:12:01PM -0800,

[PATCH v2] btrfs-progs: report I/O errors when closing the filesystem

From: Omar Sandoval If the final fsync() on the Btrfs device fails, we just swallow the error and don't alert the user in any way. This was uncovered by xfstest generic/405, which checks that mkfs fails when it encounters EIO. Signed-off-by: Omar Sandoval ---

[PATCH] btrfs-progs: report I/O errors when closing the filesystem

From: Omar Sandoval If the final fsync() on the Btrfs device fails, we just swallow the error and don't alert the user in any way. This was uncovered by xfstest generic/405, which checks that mkfs fails when it encounters EIO. Signed-off-by: Omar Sandoval ---

Re: [PATCH] Btrfs: fix file corruption after cloning inline extents

On Fri, Mar 3, 2017 at 12:36 AM, Liu Bo wrote: > On Thu, Mar 02, 2017 at 02:18:21PM -0800, Liu Bo wrote: >> On Tue, Jul 14, 2015 at 04:34:48PM +0100, fdman...@kernel.org wrote: >> > From: Filipe Manana >> > >> > Using the clone ioctl (or extent_same

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On 2017-03-03 00:56, Kai Krakow wrote: Am Thu, 2 Mar 2017 11:37:53 +0100 schrieb Adam Borowski : On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote: [1717713.408675] BTRFS warning (device dm-8): missing devices (1) exceeds the limit (0), writeable mount is not

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On 2017-03-02 19:47, Peter Grandi wrote: [ ... ] Meanwhile, the problem as I understand it is that at the first raid1 degraded writable mount, no single-mode chunks exist, but without the second device, they are created. [ ... ] That does not make any sense, unless there is a fundamental

Re: [PATCH v5] btrfs: Handle delalloc error correctly to avoid ordered extent hang

On Fri, Mar 3, 2017 at 12:45 AM, Qu Wenruo wrote: > > > At 03/03/2017 01:28 AM, Filipe Manana wrote: >> >> On Tue, Feb 28, 2017 at 2:28 AM, Qu Wenruo >> wrote: >>> >>> [BUG] >>> Reports about btrfs hang running btrfs/124 with default mount option

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

On Friday 03 March 2017 09:00:10 Qu Wenruo wrote: > > FWIW, as per my later messages, after mounting with clear_cache and > > letting > > btrfs-cleaner finish, btrfs-check did *not* print out those errors after > > running again. It's now about two weeks later that the file system is > > showing

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

On Fri, Mar 03, 2017 at 06:56:22AM +0100, Kai Krakow wrote: > > > I don't understand what problem this proscription is trying to > > > avoid. If it's OK to mount rw,degraded once, then it's OK to allow > > > it twice. If it's not OK twice, it's not OK once. > > > > Well, yeah. The current

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

On Friday 03 March 2017 09:09:57 Qu Wenruo wrote: > At 03/02/2017 05:44 PM, Marc Joliet wrote: > > On Wednesday 01 March 2017 19:14:07 Marc Joliet wrote: > >> In any > >> case, I started btrfs-check on the device itself. > > > > OK, it's still running, but the output so far is: > > > > # btrfs

[PATCH 11/17] fs, btrfs: convert compressed_bio.pending_bios from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

AFAIK, no, it hasn't been fixed, at least not in mainline, because the patches to fix it got stuck in some long-running project patch queue (IIRC, the one for on-degraded auto-device-replace), with no timeline known to me on mainline merge. Meanwhile, the problem as I understand it is that at

[PATCH 06/17] fs, btrfs: convert btrfs_delayed_ref_node.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 07/17] fs, btrfs: convert btrfs_delayed_node.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 02/17] fs, btrfs: convert btrfs_transaction.use_count from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 15/17] fs, btrfs: convert scrub_parity.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 08/17] fs, btrfs: convert btrfs_delayed_item.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 10/17] fs, btrfs: convert extent_state.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 09/17] fs, btrfs: convert btrfs_root.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 16/17] fs, btrfs: convert scrub_ctx.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 17/17] fs, btrfs: convert btrfs_raid_bio.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 00/17] fs, btrfs refcount conversions

Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free

[PATCH 13/17] fs, btrfs: convert scrub_page.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 12/17] fs, btrfs: convert scrub_recover.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 14/17] fs, btrfs: convert scrub_block.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 01/17] fs, btrfs: convert btrfs_bio.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 04/17] fs, btrfs: convert btrfs_ordered_extent.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 03/17] fs, btrfs: convert extent_map.refs from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 05/17] fs, btrfs: convert btrfs_caching_control.count from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

Am Thu, 2 Mar 2017 11:37:53 +0100 schrieb Adam Borowski : > On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote: > > [1717713.408675] BTRFS warning (device dm-8): missing devices (1) > > exceeds the limit (0), writeable mount is not allowed > > [1717713.446453] BTRFS