-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
btrfs send/receive: ERROR: send ioctl failed with -2: No such file or directory #931
Comments
The link count error is already a little concerning, it affects the fs tree and all the snapshots of that fs tree. Thus it's possible that, for example, the link count is beyond what's expected. Then during send, it needs to go through all the hard links, but failed to find the extra hard links, thus returning -ENOENT. The link count error can be fixed by "btrfs check --repair". Mind to take a try on the |
here you go! still encountered the same error, and the dumped send streams from before and after repairing are identical (compared with sha256sums). i left the byte sequences from the xattrs in the log this time, since it seems more likely that they could possibly be pertinent..
|
So the two bad nlink files looks like orphans, thus it's not referenced by any subvolume, nor contribute to the send stream. Mind to dump the following output?
The first two are just to verify the fs is fine after repair (the super block errors can be ignored, not a big deal at all). Although I'd prefer not to use option |
the check output still seems to show a lot of errors
the dump-tree output is 6.3 GiB, too big for github.. if there's a specific region of interest i can paste it, otherwise i have a compressed copy of the full version here (id prefer not to host it forever so i would be greatful if let me know when you've retrieved it/its ok to remove) |
after experiencing similar symptoms to this issue #147 (comment) i was asked to open a new issue, so here we are
btrfs-progs v6.12
linux 6.12.4
...to be honest, im not sure my filesystem qualifies as "fine"; here is what btrfs check reported:
after seeing the error seemingly occurred close to when processing the corrupt $RECYCLE.BIN directory (context #147 (comment)), my feeling is this is just due to filesystem corruption and probably not a fruitful report, but for posterity at the very least i figured i may as well post it. im happy to try any tests if there are any suggestions! (my data is safely on a new filesystem now), or if you just feel inclined to close this that works too.
The text was updated successfully, but these errors were encountered: