Hello,
(Warning: I'm a user, not a developer here.)
In my experience (on kernel 4.4) it processed larger and slower devices
within a day, BUT according to some recent topics the runaway
fragmentation (meaning in this case large number of small extents
regardless of their relative location) can significantly slow down BTRFS
operations to the point of making them infeasible. Possible reasons for
fragmentations are snapshotting volumes too often and/or running VM
images from BTRFS without taking some precautions.
On top of this, mount device name makes one suspicious there's another
layer between BTRFS and hardware. Are you sure it's not the bottleneck
in this case?
--
With Best Regards,
Marat Khalili
On 10/05/17 10:02, Stefan Priebe - Profihost AG wrote:
I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me
something about the expected runtime or how to fix bad key ordering?
Greets,
Stefan
Am 06.05.2017 um 07:56 schrieb Stefan Priebe - Profihost AG:
It's still running. Is this the normal behaviour? Is there any other way
to fix the bad key ordering?
Greets,
Stefan
Am 02.05.2017 um 08:29 schrieb Stefan Priebe - Profihost AG:
Hello list,
i wanted to check an fs cause it has bad key ordering.
But btrfscheck is now running since 7 days. Current output:
# btrfsck -p --repair /dev/mapper/crypt_md0
enabling repair mode
Checking filesystem on /dev/mapper/crypt_md0
UUID: 37b15dd8-b2e1-4585-98d0-cc0fa2a5a7c9
bad key ordering 39 40
checking extents [O]
FS is a 12TB BTRFS Raid 0 over 3 mdadm Raid 5 devices. How long should
btrfsck run and is there any way to speed it up? btrfs tools is 4.8.5
Thanks!
Greets,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
