Btrfs Raid5 issue.

I've been running btrfs in a raid5 for about a year now with bcache in front of it. Yesterday, one of my drives was acting really slow, so I was going to move it to a different port. I guess I get too comfortable hot plugging drives in at work and didn't think twice about what could go wrong, hey

Re: BTRFS warning (device dm-0): unhandled fiemap cache detected

On 2017年08月21日 11:27, Christoph Anton Mitterer wrote: On Mon, 2017-08-21 at 10:43 +0800, Qu Wenruo wrote: Harmless, it is only designed to merge fiemap output. Thanks for the info :) On Mon, 2017-08-21 at 10:57 +0800, Qu Wenruo wrote: Quite strange, according to upstream git log, that

Re: BTRFS warning (device dm-0): unhandled fiemap cache detected

On Mon, 2017-08-21 at 10:43 +0800, Qu Wenruo wrote: > Harmless, it is only designed to merge fiemap output. Thanks for the info :) On Mon, 2017-08-21 at 10:57 +0800, Qu Wenruo wrote: > Quite strange, according to upstream git log, that commit is merged  > between v4.12-rc7 and v4.12. > Maybe I

Re: BTRFS warning (device dm-0): unhandled fiemap cache detected

On 2017年08月21日 10:43, Qu Wenruo wrote: On 2017年08月21日 10:29, Christoph Anton Mitterer wrote: Hey. Just got the following with 4.12.6: Aug 21 03:29:51 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=812641906688 len=12288 flags=0x0 Aug 21

Re: BTRFS warning (device dm-0): unhandled fiemap cache detected

On 2017年08月21日 10:29, Christoph Anton Mitterer wrote: Hey. Just got the following with 4.12.6: Aug 21 03:29:51 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=812641906688 len=12288 flags=0x0 Aug 21 03:29:56 heisenberg kernel: BTRFS warning

BTRFS warning (device dm-0): unhandled fiemap cache detected

Hey. Just got the following with 4.12.6: Aug 21 03:29:51 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=812641906688 len=12288 flags=0x0 Aug 21 03:29:56 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0

Re: [PATCH preview] btrfs: allow to set compression level for zlib

On Fri, Aug 18, 2017 at 10:08 AM, David Sterba wrote: > That's quite a lot, in kernel. IIRC zlib and lzo use less than 200kb, > zstd wants 800kb for level 1. And this needs to be contiguous memory, so > if we're lucky and get the memory at the mount time, fine. In general > the

[PATCH 4/4] btrfs: Delete an unnecessary variable initialisation in tree_mod_log_eb_copy()

From: Markus Elfring Date: Sun, 20 Aug 2017 22:02:54 +0200 The variable "tm_list" will eventually be set to an appropriate pointer a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring

[PATCH 3/4] btrfs: Improve eight size determinations

From: Markus Elfring Date: Sun, 20 Aug 2017 21:55:56 +0200 Replace the specification of data types by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/4] btrfs: Adjust 32 checks for null pointers

From: Markus Elfring Date: Sun, 20 Aug 2017 21:36:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus

[PATCH 1/4] btrfs: Delete an error message for a failed memory allocation in btrfsic_process_superblock()

From: Markus Elfring Date: Sun, 20 Aug 2017 21:10:17 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 0/4] BTRFS: Adjustments for several function implementations

From: Markus Elfring Date: Sun, 20 Aug 2017 22:11:33 +0200 Some update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation in btrfsic_process_superblock() Adjust 32

[PATCH v4 3/3] Btrfs: heuristic add byte core set calculation

Calculate byte core set for data sample: Sort bucket's numbers in decreasing order Count how many numbers use 90% of sample If core set are low (<=25%), data are easily compressible If core set high (>=80%), data are not compressible Signed-off-by: Timofey Titovets ---

[PATCH v4 1/3] Btrfs: heuristic add simple sampling logic

Get small sample from input data and calculate byte type count for that sample into bucket. Bucket will store info about which bytes and how many has been detected in sample Signed-off-by: Timofey Titovets --- fs/btrfs/compression.c | 24 ++--

[PATCH v4 2/3] Btrfs: heuristic add byte set calculation

Calculate byte set size for data sample: Calculate how many unique bytes has been in sample By count all bytes in bucket with count > 0 If byte set low (~25%), data are easily compressible Signed-off-by: Timofey Titovets --- fs/btrfs/compression.c | 27

[PATCH v4 0/3] Btrfs: populate heuristic with detection logic

Based on kdave for-next As heuristic skeleton already merged Populate heuristic with basic code. First patch: add simple sampling code It's get 16 byte samples with 256 bytes shifts over input data. Collect info about how many different bytes (symbols) has been found in sample data Second patch:

Re: slow btrfs with a single kworker process using 100% CPU

I'm a btrfs user, not a developer; developers can probably provide more detailed explanation by looking at stack traces in dmesg etc., but it's possible that there's just no quick fix (yet). I presume these are 1413 _full-volume_ snapshots. Then some operations have to process

Re: slow btrfs with a single kworker process using 100% CPU

Hello, this still happens with space_cache v2. I don't think it is space_cache related? Stefan Am 17.08.2017 um 09:43 schrieb Stefan Priebe - Profihost AG: > while mounting the device the dmesg is full of: > [ 1320.325147] [] ? kthread_park+0x60/0x60 > [ 1440.330008] INFO: task