Steam on Linux makes BTRFS drive converted from NTFS read-only #51
Comments
|
What does |
|
It is also happening to me, but it automatically mounts in read only at random or at boot. Errors at boot kernel: BTRFS error (device sda1): unable to find ref byte nr 254322663424 parent 0 root 5 owner 322810 offset 0 I also tried btrfs check --repair (I know it's unrecommended) Note: I've had to compile ntfs2btrfs myself from last commit, since the one available in the Fedora repo is outdated and throws an error when used Update: I rolled back do ntfs |
|
Btrfs check reported nothing, i reformatted my drive, so i cant report any further. |
|
If Try the latest version of btrfs-progs if you can (5.18.1, I think) - I have a couple of patches in btrfs-check for undiagnosed mistakes that ntfs2btrfs was making. |
|
I think I have a similar error? I get it after using qbittorrent for a few minutes downloading to the converted partition. journalctl -p3 --since "today" | grep BTRFS I haven't run --repair and I still have the partition around so let me know if you need more info or if I should just accept it's borked and do a recovery. |
|
I ran into this same problem converting ntfs drive with steam library to btrfs went OK. the drive mounts OK, but any manipulation of the files results in: simple I'm currently running This is all done using gentoo kernel 5.19.12 (mostly identical to upstream 5.19.12) |
What version of btrfs-progs do you have installed? If not the latest (5.18.1?), does the latest also report no errors? |
I'll update to 5.19.1 and check again, but the currently running EDIT: I interrupted (Ctrl+C) the repair job and updated btrfs-progs to 5.19.1. now even simple and tons of reports like: |
|
These issues are still occuring on |
|
Same here on |
|
I encountered the same issue today, I was doing |
|
Steps to reproduce without Steam: |
|
@sleirsgoevy - Yes, thank you, that works for me. |
|
I'll have to have a proper look, but I can't see that ntfs2btrfs is doing anything obviously wrong: |
|
Thanks everybody for this - I've released a new version today which fixes these problems. There were actually two issues, neither of which was picked up by |
maharmstone
added a commit
to maharmstone/btrfs-progs
that referenced
this issue
May 1, 2023
The kernel seems to order inline extent items in a particular way: forward by sub-type, then reverse by hash. Having these out of order can cause a volume to go readonly when deleting an inode. See maharmstone/ntfs2btrfs#51 Signed-off-by: Mark Harmstone <[email protected]>
maharmstone
added a commit
to maharmstone/btrfs-progs
that referenced
this issue
May 1, 2023
For a skinny metadata item in the extent tree, the key offset represents the level of the tree it points to. This adds a check that these values match, as otherwise it can cause a volume to go readonly when deleting a large number of inodes. See maharmstone/ntfs2btrfs#51 Signed-off-by: Mark Harmstone <[email protected]>
Thank you, I've reconverted my ntfs drive into btrfs with 20230501 and it is working perfectly. |
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Sep 5, 2023
For a skinny metadata item in the extent tree, the key offset represents the level of the tree it points to. This adds a check that these values match, as otherwise it can cause a volume to go readonly when deleting a large number of inodes. See maharmstone/ntfs2btrfs#51 Pull-request: #623 Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Sep 5, 2023
For a skinny metadata item in the extent tree, the key offset represents the level of the tree it points to. This adds a check that these values match, as otherwise it can cause a volume to go readonly when deleting a large number of inodes. See maharmstone/ntfs2btrfs#51 Pull-request: #623 Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Sep 12, 2023
For a skinny metadata item in the extent tree, the key offset represents the level of the tree it points to. This adds a check that these values match, as otherwise it can cause a volume to go readonly when deleting a large number of inodes. See maharmstone/ntfs2btrfs#51 Pull-request: #623 Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Sep 12, 2023
For a skinny metadata item in the extent tree, the key offset represents the level of the tree it points to. This adds a check that these values match, as otherwise it can cause a volume to go readonly when deleting a large number of inodes. See maharmstone/ntfs2btrfs#51 Pull-request: #623 Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Oct 19, 2023
The kernel seems to order inline extent items in a particular way: forward by sub-type, then reverse by hash. Having these out of order can cause a volume to go readonly when deleting an inode. See maharmstone/ntfs2btrfs#51 With additional comments from the pull request: - lookup_inline_extent_backref() is skipping the remaining backref item if data/metadata item is smaller (either through the data hash, or metadata parent/ref_root) than the target range - the fix could be still missing in lowmem mode - image could be created according this comment maharmstone/ntfs2btrfs#51 (comment) Pull-request: #622 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Oct 19, 2023
The kernel seems to order inline extent items in a particular way: forward by sub-type, then reverse by hash. Having these out of order can cause a volume to go readonly when deleting an inode. See maharmstone/ntfs2btrfs#51 With additional comments from the pull request: - lookup_inline_extent_backref() is skipping the remaining backref item if data/metadata item is smaller (either through the data hash, or metadata parent/ref_root) than the target range - the fix could be still missing in lowmem mode - image could be created according this comment maharmstone/ntfs2btrfs#51 (comment) - due to late merge, the squota newly added key BTRFS_EXTENT_OWNER_REF_KEY was not part of the patch and the value of 'hash' needs to be verified Pull-request: #622 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Oct 19, 2023
The kernel seems to order inline extent items in a particular way: forward by sub-type, then reverse by hash. Having these out of order can cause a volume to go readonly when deleting an inode. See maharmstone/ntfs2btrfs#51 With additional comments from the pull request: - lookup_inline_extent_backref() is skipping the remaining backref item if data/metadata item is smaller (either through the data hash, or metadata parent/ref_root) than the target range - the fix could be still missing in lowmem mode - image could be created according this comment maharmstone/ntfs2btrfs#51 (comment) - due to late merge, the squota newly added key BTRFS_EXTENT_OWNER_REF_KEY was not part of the patch and the value of 'hash' needs to be verified Pull-request: #622 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
kdave
pushed a commit
to kdave/btrfs-progs
that referenced
this issue
Oct 21, 2023
The kernel seems to order inline extent items in a particular way: forward by sub-type, then reverse by hash. Having these out of order can cause a volume to go readonly when deleting an inode. See maharmstone/ntfs2btrfs#51 With additional comments from the pull request: - lookup_inline_extent_backref() is skipping the remaining backref item if data/metadata item is smaller (either through the data hash, or metadata parent/ref_root) than the target range - the fix could be still missing in lowmem mode - image could be created according this comment maharmstone/ntfs2btrfs#51 (comment) - due to late merge, the squota newly added key BTRFS_EXTENT_OWNER_REF_KEY was not part of the patch and the value of 'hash' needs to be verified Pull-request: #622 Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Windows everything works fine, but on Linux when trying to install a game or update a game, my converted drive turns into read-only
output of command "journalctl -p3 --since "today" | grep BTRFS"
Aug 02 16:03:18 localhost kernel: BTRFS error (device nvme0n1p6): qgroup generation mismatch, marked as inconsistent
Aug 02 14:06:04 localhost.localdomain kernel: BTRFS error (device sda1): unable to find ref byte nr 124385026048 parent 0 root 5 owner 33353 offset 0
Aug 02 14:06:04 localhost.localdomain kernel: BTRFS: error (device sda1: state A) in __btrfs_free_extent:3094: errno=-2 No such entry
Aug 02 14:06:04 localhost.localdomain kernel: BTRFS: error (device sda1: state EA) in btrfs_run_delayed_refs:2151: errno=-2 No such entry
Aug 02 14:08:45 localhost.localdomain kernel: BTRFS error (device sda1): unable to find ref byte nr 670268948480 parent 0 root 5 owner 92017 offset 0
Aug 02 14:08:45 localhost.localdomain kernel: BTRFS: error (device sda1: state A) in __btrfs_free_extent:3094: errno=-2 No such entry
Aug 02 14:08:45 localhost.localdomain kernel: BTRFS: error (device sda1: state EA) in btrfs_run_delayed_refs:2151: errno=-2 No such entry
Aug 02 14:14:03 localhost.localdomain kernel: BTRFS error (device sda1): unable to find ref byte nr 670268948480 parent 0 root 5 owner 92017 offset 0
Aug 02 14:14:03 localhost.localdomain kernel: BTRFS: error (device sda1: state A) in __btrfs_free_extent:3094: errno=-2 No such entry
Aug 02 14:14:03 localhost.localdomain kernel: BTRFS: error (device sda1: state EA) in btrfs_run_delayed_refs:2151: errno=-2 No such entry
drive was converted via Version 20210923
The text was updated successfully, but these errors were encountered: