On Mon, Sep 19, 2016 at 10:20:37AM +0800, Qu Wenruo wrote:
> -95 is -EOPNOTSUPP.
> Not a common errno in btrfs.
> Most EOPNOTSUPP are related to discard and crapped fallcate/drop extents.
> Then are you using discard mount option?
I did indeed have the discard mount option enabled. I tried booting with
discard disabled, but the same problem appeared.
> Normally a btrfs-debug-tree would help in most case, but this time it seems
> to be a runtime scrub bug other than on-disk metadata corruption.
> What I can see here is, with all your operation, your fs should be a normal
> btrfs, other than converted one.
> To confirm my idea, would you please upload the following things if your
> filesystem is not too large?
> # btrfs-debug-tree -t extent <your device>
> # btrfs-debug-tree -t chunk <your device>
> # btrfs-debug-tree -t dev <your device>
> There is no file/dir name/data contained in the dump. So it's just
> chunk/extent allocation info.
> You could upload them at ease.
> > Not a mess, I think it's a good bug report. I think Qu and David know
> > more about the latest iteration of the convert code. If you can wait
> > until next week at least to see if they have questions that'd be best.
> > If you need to get access to the computer sooner than later I suggest
> > btrfs-image -c9 -t4 -s to make a filename sanitized copy of the
> > filesystem metadata for them to look at, just in case. They might be
> > able to figure out the problem just from the stack trace, but better
> > to have the image before blowing away the file system, just in case
> > they want it.
> Yes, btrfs-image dump would be the best.
> Although sanitizing may takes a long time and the output may be too large.
I had posted a btrfs-image before. It was run with a single -s flag:
Here's the debug tree data:
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