btrfs
btrfs copied to clipboard
maharmstone
[Bug?] Btrfs partition goes read-only
Hello. OS: Windows 7 (Russian language) WinBtrfs: btrfs-1.8
Today I decided to try the btrfs file system on linux and windows. On the HDD, I freed 4GB from the end of the disk and created an additional partition, formatted it in btrfs. I installed the driver from "btrfs-1.8.zip", rebooted the computer, then the driver was installed and required another reboot. Immediately after installing the driver (before 1 reboot), I started testing the write speed to a partition with btrfs. So many times I copied different files, of different sizes, from 30mb to 3gb. After 1 reboot, I again continued to copy and monitor the speed of copying. At some point, either after the first or after the second reboot, I noticed that the partition went into read-only mode. Windows Explorer gave error 65535 when trying to create a directory. Photo - https://disk.yandex.ru/d/OHqBh5LKvoHPag/Windows7_Error_65535.jpg Video - https://disk.yandex.ru/d/OHqBh5LKvoHPag/Windows7_Error_65535-Video.mp4 Disk property - devices tab - https://disk.yandex.ru/d/OHqBh5LKvoHPag/Windows7_BTRFS_tab_devices.jpg Disk property - volume Usage tab - https://disk.yandex.ru/d/OHqBh5LKvoHPag/Windows7_BTRFS_tab_volumeUsage.jpg
In the video, you can see that at the root of the partition is the file "ru_windows_7_home_premium_with_sp1_x64_dvd_u_676728.iso", which weighs 3.0 GB. Only 2.7GB is available on an empty partition. Screenshot of the output of the "df -hT" command in linux - https://disk.yandex.ru/d/OHqBh5LKvoHPag/btrfs-4gb-df.png It is logical to assume that it is impossible to write a 3GB file to a partition where only 2.7GB is free. I make an assumption that this is some kind of error, as a result of which the file system switched to read-only mode.
Also after that I found another problem. After the first problem, I started writing a lot of files larger than the size of the btrfs disk partition. Surprisingly, the files continued to be written, as if the place had not run out. I do not understand what it is and how it can be at all? Video - https://disk.yandex.ru/d/OHqBh5LKvoHPag/The_files_are_larger_than_the_disk.mp4
Now the "read-only" problem is fixed after I booted Linux and started working with files on it.
What does
btrfs checksay on Linux?
$ sudo btrfs check /dev/xvdj
Opening filesystem to check...
Checking filesystem on /dev/xvdj
UUID: 37a31163-5a81-450f-a009-361337d985d7
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 3760619520 bytes used, no error found
total csum bytes: 3665692
total tree bytes: 4030464
total fs tree bytes: 32768
total extent tree bytes: 49152
btree space waste bytes: 267532
file data blocks allocated: 3869835264
referenced 3756589056
Thanks - so there's no corruption on the disk. What's /dev/xvdj, though? I don't think I've ever seen a device name like that.
What's
/dev/xvdj
This is the name of the hard disk, analogous to /dev/sda OS: Qubes Linux
What's
/dev/xvdj, though? I don't think I've ever seen a device name like that.
/dev/xvdX are virtualised Xen block devices.
Not that I can remember - I'll have to do some testing. It might be that Total Commander is doing something I've not accounted for.
I downgraded the WinBTRFS driver to v1.7.2 today to avoid the BSODs from another issue (#87).
After roughly 30GB of downloaded data from Steam, the drive went into read-only mode. After restarting the OS, it's writeable again (I can create text files) until I start Steam again, which causes the drive to go into read-only mode, again.
I didn't find anything of interest in the Windows event view.
Scrubbing the disk after a reboot when the drive is still writeable also didn't help. No errors were found and after starting Steam (which tries to continue the downloads), the drive is back into read-only.
This is what Linux btrfs finds after the drive goes into read-only:
Opening filesystem to check...
Checking filesystem on /dev/sde1
UUID: 3a2d396e-0ec9-4e5c-9975-1330bc96654f
[1/7] checking root items
[2/7] checking extents
super bytes used 79462998016 mismatches actual used 79325061120
ERROR: errors found in extent allocation tree or chunk allocation
[3/7] checking free space tree
free space info recorded 3468 extents, counted 3467
wanted bytes 425984, found 442368 for off 908148736
cache appears valid but isn't 30408704
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 78729961472 bytes used, error(s) found
total csum bytes: 77331448
total tree bytes: 137658368
total fs tree bytes: 40304640
total extent tree bytes: 10289152
btree space waste bytes: 20495731
file data blocks allocated: 505106632704
referenced 79152041984
@Schroedingers-Cat - there's not much point in logging bugs encountered in an old version.
@maharmstone anything else you might need? It could be that this issue has existed since v1.7.2, that's why I posted some details about it.
I'm having the same issue with the latest version. The drive keeps going into read-only mode shortly after boot in Windows.
I encountered this issue too. When I trying to copy a 1GiB file into a btrfs volume with 1.06GiB free space, I encountered the write protection issue after 715MiB is copied.
Winbtrfs: v1.8
Windows: Windows 11 21H2
Other software: Only Winbtrfs and VeraCrypt installed. No other software (I deployed this environment to check if Winbtrfs works with VeraCrypt)
Note: Volume is encrypted and mounted by VeraCrypt. The fs is created manually by mkfs.btrfs (from btrfs-progs) v5.16.2 under Ubuntu 22.04. The write protect is off after I remount the volume through VeraCrypt. No fs error detected by Scrub after remount.
