Bug 200255
Summary: | call trace on btrfs send/receive | ||
---|---|---|---|
Product: | File System | Reporter: | Christoph Anton Mitterer (calestyo) |
Component: | btrfs | Assignee: | BTRFS virtual assignee (fs_btrfs) |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | dsterba |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.16.16 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Christoph Anton Mitterer
2018-06-25 00:59:04 UTC
Still, as of 4.18.0 Still happens as of 4.19.28, but interestingly I had one case recently, where it didn't occur (normally it happens straight after the btrfs send … | btrfs receive is invoked). I do however not see the difference between this one time where it worked and the other times when I get the call trace. It was even on a fs, where I normally get the error. This this issue might have disappeared... at least I didn't take note of it since a while. 6480 /* 6481 * This is done when we lookup the root, it should already be complete 6482 * by the time we get here. 6483 */ 6484 WARN_ON(send_root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE); I checked the exact version 4.16.16 and it's this warning, added by commit https://git.kernel.org/linus/139f807a1eba1e484941a98fb93e . This seems to depend on the state of the fs and once there are no orphan inodes to cleanup on the given root, it won't show. It looks like it could be a problem otherwise but I'm not sure if other changes affected that. Thanks for the updates, it at least narrows down the versions where it happened for sure. (In reply to David Sterba from comment #4) > This seems to > depend on the state of the fs and once there are no orphan inodes to cleanup > on the given root, it won't show. It looks like it could be a problem > otherwise but I'm not sure if other changes affected that. You think this could have caused (or still cause) any corruptions? Closing this, since I haven't seen it in a long while. |