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 a
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 --
include/trace/e
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 sp
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 with a WARN_ON they then proceed to indiscriminately dereference the
exten
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. btrfs/130
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 fs/btrfs/extent-tre
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 s
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 h
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 two
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 s
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 w
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, u64 tree_size),
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
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 ERR_PTR
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
On Tue, Jul 11, 2017 at 10:48 AM, Marc MERLIN wrote:
> 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
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 a
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 complete
在 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
wait_for_commit+0x4a/0x
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 the gcc bug, I use
Signed-off-by: Nikolay Borisov
---
fs/btrfs/relocation.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 65661d1aae4e..1a532bb72eab 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1308,8 +1308,6 @@ static int __must_check
insert_into_bitmap has only one caller which always allocates the info struct
passed. As such remove the any NULL checks for info and also remove code
to allocate info in case it was NULL.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/free-space-cache.c | 13 +
1 file changed, 1 insert
The current code was erroneously checking for root_level > BTRFS_MAX_LEVEL. If
we had a root_level of 8 then the check won't trigger and we could
potentially hit a buffer overflow. The correct check should be
root_level >= BTRFS_MAX_LEVEL
Signed-off-by: Nikolay Borisov
---
fs/btrfs/qgroup.c | 4
23 matches
Mail list logo
