First of all.
The "crossing stripe boundary" error message itself is *HARMLESS* for
recent kernels.
It only means, that metadata extent won't be checked by scrub on recent
kernels.
Because scrub by its codes, has a limitation that, it can only check
tree blocks which are inside a 64K block.
Old kernel won't have anything wrong, until that tree block is being
scrubbed.
When scrubbed, old kernel just BUG_ON().
Now recent kernel will handle such limitation by checking extent
allocation and avoid crossing boundary, so new created fs with new
kernel won't cause such error message at all.
But for old created fs, the problem can't be avoided, but at least, new
kernels will not BUG_ON() when you scrub these extents, they just get
ignored (not that good, but at least no BUG_ON).
And new fsck will check such case, gives such warning.
Overall, you're OK if you are using recent kernels.
Marc Haber wrote on 2016/03/29 08:43 +0200:
On Mon, Mar 28, 2016 at 03:35:32PM -0400, Austin S. Hemmelgarn wrote:
Did you convert this filesystem from ext4 (or ext3)?
No.
You hadn't mentioned what version of btrfs-progs you're using, and that is
somewhat important for recovery. I'm not sure if current versions of btrfs
check can fix this issue, but I know for a fact that older versions (prior
to at least 4.1) can not fix it.
4.1 for creation and btrfs check.
I assume that you have run older kernel on it, like v4.1 or v4.2.
In those old kernels, it lacks the check to avoid such extent allocation
check.
As far as what the kernel is involved with, the easy way to check is if it's
operating on a mounted filesystem or not. If it only operates on mounted
filesystems, it almost certainly goes through the kernel, if it only
operates on unmounted filesystems, it's almost certainly done in userspace
(except dev scan and technically fi show).
Then btrfs check is a userspace-only matter, as it wants the fs
unmounted, and it is irrelevant that I did btrfs check from a rescue
system with an older kernel, 3.16 if I recall correctly.
Not recommended to use older kernel to RW mount or use older fsck to do
repair.
As it's possible that older kernel/btrfsck may allocate extent that
cross the 64K boundary.
2. Regarding general support: If you're using an enterprise distribution
(RHEL, SLES, CentOS, OEL, or something similar), you are almost certainly
going to get better support from your vendor than from the mailing list or
IRC.
My "productive" desktops (fan is one of them) run Debian unstable with
a current vanilla kernel. At the moment, I can't use 4.5 because it
acts up with KVM. When I need a rescue system, I use grml, which
unfortunately hasn't released since November 2014 and is still with
kernel 3.16
To fix your problem(make these error message just disappear, even they
are harmless on recent kernels), the most easy one, is to balance your
metadata.
As I explained, the bug only lies in metadata, and balance will allocate
new tree blocks, then copy old data into new locations.
In the allocation process of recent kernel, it will avoid such cross
boundary, and to fix your problem.
But if you are using old kernels, don't scrub your metadata.
Thanks,
Qu
Greetings
Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
