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 phys=812641906688 len=12288 flags=0x0 Aug 21 03:30:58 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=813760614400 len=32768 flags=0x0 Aug 21 03:31:15 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=812641906688 len=12288 flags=0x0
Is it what should be fixed with:
https://patchwork.kernel.org/patch/9803291/
?
Is this harmless or must I assume that some part of my data/fs is now corrupt and should I recover from backup?
Thanks,
Chris.
Quoted 8 lines · Christoph Anton Mitterer
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 phys=812641906688 len=12288 flags=0x0 Aug 21 03:30:58 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=813760614400 len=32768 flags=0x0 Aug 21 03:31:15 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=812641906688 len=12288 flags=0x0
This is just warning about there is some fiemap extent cached but not submitted. So in fact harmless, only mean to info developers.
Quoted 5 lines
Is it what should be fixed with:
https://patchwork.kernel.org/patch/9803291/?
But it is already in v4.12, so there is some other case I missed.
Any reproducer?
Quoted 3 lines
Is this harmless or must I assume that some part of my data/fs is now corrupt and should I recover from backup?
Harmless, it is only designed to merge fiemap output. No data is touched at all.
Sorry for the trouble.
Thanks,
Qu
Quoted 4 lines
Thanks,
Chris.
Quoted 15 lines · Qu Wenruo
Quoted 8 lines · Christoph Anton Mitterer
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 phys=812641906688 len=12288 flags=0x0 Aug 21 03:30:58 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=813760614400 len=32768 flags=0x0 Aug 21 03:31:15 heisenberg kernel: BTRFS warning (device dm-0): unhandled fiemap cache detected: offset=0 phys=812641906688 len=12288 flags=0x0This is just warning about there is some fiemap extent cached but not submitted. So in fact harmless, only mean to info developers.
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
Is it what should be fixed with:
https://patchwork.kernel.org/patch/9803291/?
But it is already in v4.12, so there is some other case I missed.
Any reproducer?
OK, I checked the v4.12.6 code, and it doesn't have the fix.
While v4.12.8 (current Archlinux official repo linux package) has the fix. If you're using Arch, updating linux will solve the problem.
Quite strange, according to upstream git log, that commit is merged between v4.12-rc7 and v4.12. Maybe I misunderstand the stable kernel release cycle.
Thanks,
Qu
Quoted 21 lines
Quoted 4 lines
Is this harmless or must I assume that some part of my data/fs is now corrupt and should I recover from backup?
Harmless, it is only designed to merge fiemap output. No data is touched at all.
Sorry for the trouble.
Thanks,
QuQuoted 4 lines
Thanks,
Chris.Signature · 3 lines
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
Quoted 1 line · Qu Wenruo
Harmless, it is only designed to merge fiemap output.
Thanks for the info :)
Quoted 3 lines · Qu Wenruo
Quite strange, according to upstream git log, that commit is merged between v4.12-rc7 and v4.12.
Maybe I misunderstand the stable kernel release cycle.
Seems it was only added in 4.12.7? Maybe a typo?
Cheers,
Chris.
Quoted 11 lines · Christoph Anton Mitterer
Quoted 1 line · Qu Wenruo
Harmless, it is only designed to merge fiemap output.
Thanks for the info :)
Quoted 3 lines · Qu Wenruo
Quite strange, according to upstream git log, that commit is merged between v4.12-rc7 and v4.12.
Maybe I misunderstand the stable kernel release cycle.Seems it was only added in 4.12.7? Maybe a typo?
I'm talking about upstream, which is managed by Linus. The 4.12.x is managed by maintainers of stable releases.
In Linus repo, the commit is between v4.12 and v4.12-rc7 tag. Maybe v4.12.x is started before v4.12 release.
Thanks,
Qu
Quoted 4 lines
Cheers,
Chris.
Quoted 13 lines · Qu Wenruo
Quoted 10 lines · Christoph Anton Mitterer
Quoted 1 line · Qu Wenruo
Harmless, it is only designed to merge fiemap output.
Thanks for the info :)
Quoted 3 lines · Qu Wenruo
Quite strange, according to upstream git log, that commit is merged between v4.12-rc7 and v4.12.
Maybe I misunderstand the stable kernel release cycle.
Quoted 7 lines
Quoted 1 line
Seems it was only added in 4.12.7? Maybe a typo?
I'm talking about upstream, which is managed by Linus. The 4.12.x is managed by maintainers of stable releases.
In Linus repo, the commit is between v4.12 and v4.12-rc7 tag. Maybe v4.12.x is started before v4.12 release.
It's not in 4.12.
$ git tag --contains 848c23b78fafdcd3270b06a30737f8dbd70c347f for-4.13-part2-tag v4.13-rc1 v4.13-rc2 v4.13-rc3 v4.13-rc4 v4.13-rc5