-
Notifications
You must be signed in to change notification settings - Fork 29
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
Bad filesystem state after converting two separate NTFS partitions to BTRFS #23
Comments
Just wanted to chime in, this was exactly my experience as well. Unfortunately, I nuked the fs and restored a backup, otherwise I'd post the dmesg output too, but just wanted to indicate I had the same experience in just the last few days. Also on Arch with kernel 5.12. |
Glad to know I am not the only one. Seems like ntfs2btrfs isn't really reliable right now. I am also thinking about nuking the FS and just formatting it as BTRFS from Linux, but I'll wait a few more days for a dev response in case they need some extra debug info. |
Same experience as well (issue #16) |
Yep. I have a lot of issues after converting partition with ntfs2btrfs. btrfs check (with or without --repair) report no errors. Trying to use the partition cause a lot of: __btrfs_free_extent or btrfs_del_csums (errno=-75 unknown) errors. For test I'm using: Path of Exile game client, which trying to update its Content.ggpk EDIT: I had this 4cc5a32 ntfs2btrfs version |
Thanks. Errno 75 is EOVERFLOW, which as far as I can tell probably originates in My guess would be that it comes from the FIXME at: Line 2668 in 226f55f
|
'__btrfs_free_extent__btrfs_free_extent' also comes with 'errno=-2 No such entry' I already drop this bugged partition and recreate it freshly under linux - no issues so far. New tests should be done on clear, freshly converted partition after a fix. What is worrying me the most - 'btrfs checks' sees no issues with a filesystem, regardless some fundamentals errors persists (based on fact using fs causing a lot of btrfs errors and ro access shortly after a mount) on a filesystem. btrfs is good, but 'btrfs check' has to be a better utility with deeper analysis. |
I agree - once I figure out what the issue is, I'll submit a patch to them when I get the chance. |
I managed to reproduce this:
This happened consistently when I did |
You are right. I did remove subvolume. My kernel is 5.10.0-8-amd64 |
This is fixed as of the latest master. |
My tool ntfs2btrfs has been creating btrfs volumes in a way that the kernel doesn't like, but which isn't picked up by btrfs check - see maharmstone/ntfs2btrfs#23 for the details, including a backtrace. This patch adds a check for when a csum item contains too many entries - effectively it ensures that there's always at least sizeof(struct btrfs_item) bytes free in the tree, otherwise btrfs_del_csums can throw an error. max_entries is the value of the __MAX_CSUM_ITEMS macro in fs/btrfs/file-item.c. Pull-request: #401 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
My tool ntfs2btrfs has been creating btrfs volumes in a way that the kernel doesn't like, but which isn't picked up by btrfs check - see maharmstone/ntfs2btrfs#23 for the details, including a backtrace. This patch adds a check for when a csum item contains too many entries - effectively it ensures that there's always at least sizeof(struct btrfs_item) bytes free in the tree, otherwise btrfs_del_csums can throw an error. max_entries is the value of the __MAX_CSUM_ITEMS macro in fs/btrfs/file-item.c. Pull-request: #401 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
My tool ntfs2btrfs has been creating btrfs volumes in a way that the kernel doesn't like, but which isn't picked up by btrfs check - see maharmstone/ntfs2btrfs#23 for the details, including a backtrace. This patch adds a check for when a csum item contains too many entries - effectively it ensures that there's always at least sizeof(struct btrfs_item) bytes free in the tree, otherwise btrfs_del_csums can throw an error. max_entries is the value of the __MAX_CSUM_ITEMS macro in fs/btrfs/file-item.c. Pull-request: #401 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
My tool ntfs2btrfs has been creating btrfs volumes in a way that the kernel doesn't like, but which isn't picked up by btrfs check - see maharmstone/ntfs2btrfs#23 for the details, including a backtrace. This patch adds a check for when a csum item contains too many entries - effectively it ensures that there's always at least sizeof(struct btrfs_item) bytes free in the tree, otherwise btrfs_del_csums can throw an error. max_entries is the value of the __MAX_CSUM_ITEMS macro in fs/btrfs/file-item.c. Pull-request: kdave#401 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
I've converted two NTFS partitions now using this tool and both filesystems have had issues that would cause it to drop down into read only mode. Scrub seems to work okay, indicating that the data is at least not corrupted, but attempting to remove
image/ntfs.img
or doing a defrag will cause the mount to switch into read-only mode.Below is what I got in my system logs after I finished converting a 2TB Western Digital My Passport external USB disk and then attempted to delete the
image
subvolume.Steps to reproduce
ntfs2btrfs /dev/sdf1
mount -o compress-force=zstd:2 /dev/sdf1 "/mnt/My Passport"
btrfs subvolume delete "/mnt/My Passport/image"
I did the conversion on an up-to-date Arch system using a June 14 build of ntfs2btrfs from the AUR.
Kernel 5.12.10-arch1-1
btrfs-progs 5.12.1
Similar issues occured with a Seagate 4TB SHDD.
The text was updated successfully, but these errors were encountered: