Re: [PATCH v2 3/4] btrfs: Add zstd support

On Tue, Jul 11, 2017 at 06:01:38AM +, Nick Terrell wrote: > On 7/10/17, 9:57 PM, "Nick Terrell" wrote: > > The problem is caused by a gcc-7 bug [1]. It miscompiles > > ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0. > > Sorry, my patch still triggered

Re: [RFC PATCH] btrfs: qgroup: Fix hang when using inode_cache and qgroup

在 2017年06月06日 01:38, Goldwyn Rodrigues 写道: On 05/31/2017 03:08 AM, Qu Wenruo wrote: Commit 48a89bc4f2ce ("btrfs: qgroups: Retry after commit on getting EDQUOT") is causing hang, with the following backtrace: Call Trace: __schedule+0x374/0xaf0 schedule+0x3d/0x90

Re: [PATCH v2 08/13] btrfs: convert prelimary reference tracking to use rbtrees

On 07/11/2017 09:15 AM, David Sterba wrote: > On Wed, Jun 28, 2017 at 09:57:00PM -0600, Edmund Nadolski wrote: >> It's been known for a while that the use of multiple lists >> that are periodically merged was an algorithmic problem within >> btrfs. There are several workloads that don't

Re: BTRFS: error (device dm-2) in btrfs_run_delayed_refs:2960: errno=-17 Object already exists

On Tue, Jul 11, 2017 at 04:43:06PM -0600, Chris Murphy wrote: > Assuming it works, settle on 4.9 until 4.14 shakes out a bit. Given > your setup and the penalty for even small problems, it's probably > better to go low risk and that means longterm kernels. Maybe one of > the three systems can use

[PATCH] Btrfs: report errors when checksum is not found

When btrfs fails the checksum check, it'll fill the whole page with "1". However, if %csum_expected is 0 (which means there is no checksum), then for some unknown reason, we just pretend that the read is correct, so userspace would be confused about the dilemma that read is successful but getting

Re: [PATCH] btrfs: Prevent possible ERR_PTR() dereference

On 11.07.2017 20:24, David Sterba wrote: > On Tue, Jul 11, 2017 at 04:55:51PM +0300, Nikolay Borisov wrote: >> In btrfs_full_stripe_len/btrfs_is_parity_mirror we have similar code which >> gets the chunk map for a particular range via get_chunk_map. However, >> get_chunk_map can return an

"Unable to find ref byte nr ...." (4.11 somehow fishy?)

Hi, My external drive (single metadata, inline) caused an Ooops recently and went read-only. I wonder, has this something to do with the btrfs issues some have with 4.11? Best regards, Clemens [ 619.850316] perf: interrupt took too long (3958 > 3941), lowering kernel.perf_event_max_sample_rate

Re: [PATCH v2 10/13] btrfs: backref, add tracepoints for prelim_ref insertion and merging

On Wed, Jun 28, 2017 at 09:57:02PM -0600, Edmund Nadolski wrote: > From: Jeff Mahoney > +DECLARE_EVENT_CLASS(btrfs__prelim_ref, > + TP_PROTO(const struct btrfs_fs_info *fs_info, > + const struct prelim_ref *oldref, > + const struct prelim_ref *newref,

Re: [PATCH] btrfs: Prevent possible ERR_PTR() dereference

On Tue, Jul 11, 2017 at 04:55:51PM +0300, Nikolay Borisov wrote: > In btrfs_full_stripe_len/btrfs_is_parity_mirror we have similar code which > gets the chunk map for a particular range via get_chunk_map. However, > get_chunk_map can return an ERR_PTR value and while the 2 callers do catch > this

Re: [PATCH] btrfs: Remove redundant checks from btrfs_alloc_data_chunk_ondemand

On Tue, Jul 11, 2017 at 01:47:50PM +0300, Nikolay Borisov wrote: > Many commits ago the data space_info in alloc_data_chunk_ondemand used to be > acquired from the inode. At that point commit > 33b4d47f5e24 ("Btrfs: deal with NULL space info") got introduced to deal with > spurios cases where the

Re: [PATCH] btrfs: Remove redundant argument of flush_space

On Tue, Jul 11, 2017 at 01:25:13PM +0300, Nikolay Borisov wrote: > All callers of flush_space pass the same number for orig/num_bytes > arguments. Let's remove one of the numbers and also modify the trace point > to show only a single number - bytes requested. Seems that last point where the

Re: [PATCH] btrfs: resume qgroup rescan on rw remount

On Mon, Jul 10, 2017 at 04:56:36PM +0300, Nikolay Borisov wrote: > On 10.07.2017 16:12, Nikolay Borisov wrote: > > On 4.07.2017 14:49, Aleksa Sarai wrote: > >> Several distributions mount the "proper root" as ro during initrd and > >> then remount it as rw before pivot_root(2). Thus, if a rescan

Re: BTRFS: error (device dm-2) in btrfs_run_delayed_refs:2960: errno=-17 Object already exists

On Tue, Jul 11, 2017 at 10:00:40AM -0600, Chris Murphy wrote: > > ---[ end trace feb4b95c83ac065f ]--- > > BTRFS: error (device dm-2) in btrfs_run_delayed_refs:2960: errno=-17 Object > > already exists > > BTRFS info (device dm-2): forced readonly > > You've already had this same traceback, not

Re: BTRFS: error (device dm-2) in btrfs_run_delayed_refs:2960: errno=-17 Object already exists

On Tue, Jul 11, 2017 at 12:21 AM, Marc MERLIN wrote: > Looks like btrfs has decided to give me hell. > I'm still recovering my system. > The biggest filesystem seems to work, but I just had it go read only: > > [ cut here ] > WARNING: CPU: 5 PID: 3734 at

Re: [PATCH v2 08/13] btrfs: convert prelimary reference tracking to use rbtrees

On Wed, Jun 28, 2017 at 09:57:00PM -0600, Edmund Nadolski wrote: > It's been known for a while that the use of multiple lists > that are periodically merged was an algorithmic problem within > btrfs. There are several workloads that don't complete in any > reasonable amount of time (e.g.

[PATCH] btrfs: Remove redundant checks from btrfs_alloc_data_chunk_ondemand

Many commits ago the data space_info in alloc_data_chunk_ondemand used to be acquired from the inode. At that point commit 33b4d47f5e24 ("Btrfs: deal with NULL space info") got introduced to deal with spurios cases where the space info could be null, following a rebalance. Nowadays, however, the

[PATCH] btrfs: Remove redundant argument of flush_space

All callers of flush_space pass the same number for orig/num_bytes arguments. Let's remove one of the numbers and also modify the trace point to show only a single number - bytes requested. Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 18

Re: [PATCH 00/19] fs_info refactor part 2 (disk-io.h and volumes.h based)

Any comment? Thanks, Qu 在 2017年06月13日 17:19, Qu Wenruo 写道: This is the part 2 patchset to refactor btrfs_root usage to btrfs_fs_info. The most obvious advantage is to make function calls a little shorter, and less confused. Function calls like btrfs_alloc_data_chunk() needs caller to pass

BTRFS: error (device dm-2) in btrfs_run_delayed_refs:2960: errno=-17 Object already exists

Looks like btrfs has decided to give me hell. I'm still recovering my system. The biggest filesystem seems to work, but I just had it go read only: [ cut here ] WARNING: CPU: 5 PID: 3734 at fs/btrfs/extent-tree.c:2960 btrfs_run_delayed_refs+0xb6/0x1dc BTRFS: Transaction

Re: [PATCH v2 3/4] btrfs: Add zstd support

On 7/10/17, 9:57 PM, "Nick Terrell" wrote: > The problem is caused by a gcc-7 bug [1]. It miscompiles > ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0. > It only happens when it can't analyze ZSTD_copy8(), which is the case in > the kernel, because