Disk stops being allowed to be written to because of Write Protection. about btrfs HOT 42 CLOSED

I wonder if this has been fixed because of the recent changes.

from btrfs.

If it drops into readonly mode, it's because it thinks it's about to corrupt things. Could you send me the output of btrfs check on Linux please?

from btrfs.

Does Bash on Windows count? Or do I really need to use a Live USB for this?

from btrfs.

btrfs-tools on windows (WSL) doesn't recognize it as a btrfs fs.

from btrfs.

It'll have to be actual Linux - LXSS doesn't expose the block devices.

from btrfs.

@maharmstone

Checking filesystem on /dev/sdc2
UUID: 22df59f8-1133-60e0-30ed-65f570024c5f
checking extents
checking free space cache
Wanted offset 12615680, found 12582912
Wanted offset 12615680, found 12582912
cache appears valid but isn't 12582912
ERROR: errors found in free space cache
found 1088368812032 bytes used, error(s) found
total csum bytes: 1059724884
total tree bytes: 2100871168
total fs tree bytes: 923746304
total extent tree bytes: 68419584
btree space waste bytes: 87633016
file data blocks allocated: 1417703604224
 referenced 1086379446272

Had a friend help me with the commands since I didn't really know how Linux handles partitions and drives. Should I run btrfs check --repair on this drive, or is there another solution?

from btrfs.

Hello and thanks for that great work,
i got the same problems with the read only mode. A filesystem-"Scrub" in Windows says "not writeable" and could not start and solve the problem.
An "btrfs check --repair /dev/..." in Linux solved the problem with a message like " free disk cache not valid an was dropped".
After reboot to Windows everything works well and no loss of data was detected.
Disk configuration:
sda, sdc are Segate FireCuda 2 TB SSHD
sdb is a 240 GB SSD
sda1 + sdc1 as Raid1 via btrfs
sdbX partitions for operating systems

(i got some other issues, but will tell them in extra posts)

EDIT: console output:

btrfs check /dev/sda1
Checking filesystem on /dev/sda1
UUID: 6fbb73da-1093-409b-a6ba-7efe44b255b4
checking extents
checking free space cache
free space inode generation (0) did not match free space cache generation (3667)
free space inode generation (0) did not match free space cache generation (3728)
free space inode generation (0) did not match free space cache generation (5176)
free space inode generation (0) did not match free space cache generation (5343)
free space inode generation (0) did not match free space cache generation (4262)
free space inode generation (0) did not match free space cache generation (3749)
free space inode generation (0) did not match free space cache generation (3728)
free space inode generation (0) did not match free space cache generation (3745)
There is no free space entry for 375836094464-375836102656
There is no free space entry for 375836094464-375838998528
cache appears valid but isnt 374765256704
There is no free space entry for 376837570560-376837582848
There is no free space entry for 376837570560-376912740352
cache appears valid but isnt 375838998528
free space inode generation (0) did not match free space cache generation (3745)
There is no free space entry for 380944732160-380946100224
There is no free space entry for 380944732160-381207707648
cache appears valid but isnt 380133965824
Wanted bytes 864256, found 69632 for off 382275899392
Wanted bytes 5550080, found 69632 for off 382275899392
cache appears valid but isnt 381207707648
Wanted bytes 888832, found 688128 for off 382844739584
Wanted bytes 510451712, found 688128 for off 382844739584
cache appears valid but isnt 382281449472
free space inode generation (0) did not match free space cache generation (3773)
free space inode generation (0) did not match free space cache generation (2799)
free space inode generation (0) did not match free space cache generation (2799)
free space inode generation (0) did not match free space cache generation (3773)
...
free space inode generation (0) did not match free space cache generation (<some nums>)
...
free space inode generation (0) did not match free space cache generation (2799)
found 522024221320 bytes used err is -22
total csum bytes: 1086339092
total tree bytes: 1798619136
total fs tree bytes: 586170368
total extent tree bytes: 48709632
btree space waste bytes: 148472117
file data blocks allocated: 1310093033472
 referenced 1112516554752
Btrfs v3.12

btrfs check --repair /dev/sda1
enabling repair mode
Checking filesystem on /dev/sda1
UUID: 6fbb73da-1093-409b-a6ba-7efe44b255b4
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 522024221320 bytes used err is 0
total csum bytes: 1086339092
total tree bytes: 1798619136
total fs tree bytes: 586170368
total extent tree bytes: 48709632
btree space waste bytes: 148472117
file data blocks allocated: 1310093033472
 referenced 1112516554752
Btrfs v3.12

from btrfs.

I recently started running into this issue myself. My hdd goes write protected within a few minutes of boot. However, btrfs check --clear-space-cache v1 /dev/sd... seems to fix the issue within Linux. Should I attempt btrfs check --repair /dev/sd...? The man pages seem to discourage its use if something else works.

Will provide the output as soon as I reboot.

from btrfs.

Initial btrfs check:

Checking filesystem on /dev/sda3
UUID: f3ac28c1-20d6-4d66-b74f-b2847156e021
checking extents
checking free space cache
block group 489655631872 has wrong amount of free space
failed to load free space cache for block group 489655631872
block group 504688017408 has wrong amount of free space
failed to load free space cache for block group 504688017408
block group 519720402944 has wrong amount of free space
failed to load free space cache for block group 519720402944
block group 534752788480 has wrong amount of free space
failed to load free space cache for block group 534752788480
block group 578776203264 has wrong amount of free space
failed to load free space cache for block group 578776203264
block group 603472265216 has wrong amount of free space
failed to load free space cache for block group 603472265216
block group 628168327168 has wrong amount of free space
failed to load free space cache for block group 628168327168
block group 642126970880 has wrong amount of free space
failed to load free space cache for block group 642126970880
block group 656085614592 has wrong amount of free space
failed to load free space cache for block group 656085614592
block group 679707934720 has wrong amount of free space
failed to load free space cache for block group 679707934720
block group 725878833152 has wrong amount of free space
failed to load free space cache for block group 725878833152
block group 726952574976 has wrong amount of free space
failed to load free space cache for block group 726952574976
block group 728026316800 has wrong amount of free space
failed to load free space cache for block group 728026316800
block group 729100058624 has wrong amount of free space
failed to load free space cache for block group 729100058624
block group 730173800448 has wrong amount of free space
failed to load free space cache for block group 730173800448
block group 731247542272 has wrong amount of free space
failed to load free space cache for block group 731247542272
block group 732321284096 has wrong amount of free space
failed to load free space cache for block group 732321284096
block group 733395025920 has wrong amount of free space
failed to load free space cache for block group 733395025920
block group 734468767744 has wrong amount of free space
failed to load free space cache for block group 734468767744
block group 735542509568 has wrong amount of free space
failed to load free space cache for block group 735542509568
block group 736616251392 has wrong amount of free space
failed to load free space cache for block group 736616251392
block group 737689993216 has wrong amount of free space
failed to load free space cache for block group 737689993216
block group 738763735040 has wrong amount of free space
failed to load free space cache for block group 738763735040
block group 739837476864 has wrong amount of free space
failed to load free space cache for block group 739837476864
block group 740911218688 has wrong amount of free space
failed to load free space cache for block group 740911218688
block group 741984960512 has wrong amount of free space
failed to load free space cache for block group 741984960512
block group 743058702336 has wrong amount of free space
failed to load free space cache for block group 743058702336
block group 744132444160 has wrong amount of free space
failed to load free space cache for block group 744132444160
block group 745206185984 has wrong amount of free space
failed to load free space cache for block group 745206185984
block group 746279927808 has wrong amount of free space
failed to load free space cache for block group 746279927808
block group 747353669632 has wrong amount of free space
failed to load free space cache for block group 747353669632
block group 748427411456 has wrong amount of free space
failed to load free space cache for block group 748427411456
checking fs roots
checking csums
checking root refs
found 398823608320 bytes used, no error found
total csum bytes: 387417128
total tree bytes: 2189131776
total fs tree bytes: 1571454976
total extent tree bytes: 174440448
btree space waste bytes: 373364100
file data blocks allocated: 1703333974016
 referenced 547342434304

The fix:

btrfs check --clear-space-cache v1 /dev/sda3
Checking filesystem on /dev/sda3
UUID: f3ac28c1-20d6-4d66-b74f-b2847156e021
Clearing free space cache
Free space cache cleared

Post fix check:

Checking filesystem on /dev/sda3
UUID: f3ac28c1-20d6-4d66-b74f-b2847156e021
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 398779387904 bytes used, no error found
total csum bytes: 387417128
total tree bytes: 2189082624
total fs tree bytes: 1571454976
total extent tree bytes: 174440448
btree space waste bytes: 373384714
file data blocks allocated: 1703289802752
 referenced 547298263040

Rebooting to Windows to see if it will take.

from btrfs.

@Aliervo You should be just fine if you use that command. I know the man pages discourage it, but I did it anyway and nothing catastrophic happened, although, your mileage may vary.

I'm not sure if the write protection is a Windows 10 thing, it does seem to happen if I try to write a lot of data to a btrfs partition disk at a single time. Hopefully it gets investigated and fixed.

from btrfs.

Same issue here on Windows 10 Pro 1709 Build 16299.431. Only happens in Win10, same partition under Ubuntu 17.04 works perfect. Reboot of Win10 also fixes issue for a short while - happens also if bigger volume of data is written do disk >50MB. Is there a fix somewhere already? Only this prevents usage for me on dual-boot system. Thank you very much! Seems to be the same as #58

from btrfs.

btrfs check results:
btrfs check /dev/sdb1 Checking filesystem on /dev/sdb1 UUID: 139ae84a-f608-4e68-aa28-fa0e38d3e09a checking extents checking free space cache checking fs roots root 5 inode 275 errors 200, dir isize wrong root 5 inode 22353 errors 1, no inode item unresolved ref dir 275 index 22 namelen 26 name ._sync_3689026d816a.db-shm filetype 1 errors 5, no dir item, no inode ref root 5 inode 22356 errors 2, no orphan item root 5 inode 22361 errors 1, no inode item unresolved ref dir 275 index 26 namelen 26 name ._sync_3689026d816a.db-shm filetype 1 errors 5, no dir item, no inode ref root 5 inode 40875 errors 1, no inode item unresolved ref dir 275 index 21 namelen 26 name ._sync_3689026d816a.db-shm filetype 1 errors 5, no dir item, no inode ref ERROR: errors found in fs roots found 139713556480 bytes used, error(s) found total csum bytes: 136186828 total tree bytes: 222593024 total fs tree bytes: 46907392 total extent tree bytes: 21692416 btree space waste bytes: 24862735 file data blocks allocated: 139490963456 referenced 140438024192

btrfs check --clear-space-cache v1 doesn't solve the problem unfortunately ...
btrfs check --repair solved the issue.

from btrfs.

Haven't been here in a while because I had found a work-around... Stop Steam from auto-starting. Unfortunately, I can confirm as of today that it still exists because I made the mistake of trying to play a steam game :/ Seems like maybe it has something to do with steam always trying to update itself or something else right away, and therefore always quickly writing a bunch to the disk. Could the solution be as simple as raising the threshold for the write-protection lock?

Same error as I had before, so no new info unfortunately. On the bright side, nothing has been corrupted for me yet either!

from btrfs.

Use fastcopy or other tools help you copy files -- this works.

from btrfs.

Nope. See #81, too.

from btrfs.

With winbtrfs 1.2.1, I hit this when copying a bunch of files. 'btrfs check' on linux shows:

[root@shiny ~]# btrfs check --repair -p /dev/md126p6 | tee btrfs-check.out
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/md126p6
UUID: eb57a951-7723-4f5d-8b8e-a7cfb35b5600
Fixed 0 roots. root items                      (0:00:05 elapsed, 511346 items checked)
[1/7] checking root items                      (0:00:06 elapsed, 627490 items checked)
No device size related problem found           (0:00:14 elapsed, 82743 items checked)
[2/7] checking extents                         (0:00:14 elapsed, 83841 items checked)
cache and super generation don't match, space cache will be invalidated
[3/7] checking free space cache                (0:00:00 elapsed)
[4/7] checking fs roots                        (0:00:02 elapsed, 80633 items checked)
[5/7] checking csums (without verifying data)  (0:00:00 elapsed, 1 items checked)
[7/7] checking quota groups skipped (not enabled on this FS)
[6/7] checking root refs                       (0:00:00 elapsed, 4 items checked)
found 1071096799232 bytes used, no error found
total csum bytes: 0
total tree bytes: 1373503488
total fs tree bytes: 1324711936
total extent tree bytes: 48414720
btree space waste bytes: 239738589
file data blocks allocated: 86189244682240
 referenced 2197819080704

Any ideas?

from btrfs.

I wonder if the no free space bug is related to this.

from btrfs.

Has the root cause of this issue ever been found? This issue seems to happen consistently if I install games to the drive concurrently, one after another. I imagine you could reproduce the bug by just continually filling the drive with files the size of 1 gigabyte until the drive either Write Protects or Cyclic Redundancy occurs (the latter being solvable by just restarting the computer).

There is also another issue very closely related: #69

from btrfs.

I've never been able to reproduce this. What games in particular? Which RAID level are you using, if any?

from btrfs.

Starz0r, what version of Winbtrfs are you trying out currently?

I had experienced the same problem with earlier versions, but since v1.2 or so haven't been able to reproduce it by copying our whole family home directory (202 GB) over to the Winbtrfs volume. We've been using Winbtrfs for everything except Windows apps and system, and so far it has been working fine (yes, someone is now using this for more than experiments :-). This is a 1.2TB btrfs volume on top of BIOS-RAID1.

from btrfs.

@elliotclee I've been using v1.3 on Redstone 6 and having these issues. Using the same partition I've created since v1.0.

from btrfs.

Can you please post the output of btrfs check on Linux?

from btrfs.

@maharmstone

$ btrfs check /mnt/sdb1
ERROR: not a regular file or block device: /mnt/sdb1
ERROR: not a file system

from btrfs.

You have to check the (unmounted) block device, it's in /dev/ (use lsblk for more info on all available blockdevs).

from btrfs.

@Atemu My bad, it's been awhile since I've had to run interactive commands on an unmounted block device.

@maharmstone Sorry for taking so long to get to this, but the output is very underwhelming, which makes me very sad that I took so long to get around to this.

$ sudo btrfs check /dev/sdd1
Opening filesystem to check...
Checking filesystem on /dev/sdd1
UUID: 12d02c2b-0359-23c0-61ab-57b47ea76556
[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 2329700466688 bytes used, no error found
total csum bytes: 2292075136
total tree bytes: 4298424320
total fs tree bytes: 1436385280
total extent tree bytes: 202342400
btree space waste bytes: 508967395
file data blocks allocated: 26321073291264
 referenced 2339075792896

from btrfs.

from btrfs.

@elliotclee I have two computer with this driver installed, that first response was with another computer, the second response was with my main computer. The devices were probably assigned to different blocks per hardware configuration, not to mention the first test was done with Ubuntu 17 and the second was done with Ubuntu 19.

from btrfs.

I think its because of #164. Since I get write protection to be enabled (until rebooting the VM) because of the batch file that is in the attached zip archive.

from btrfs.

I found a new way to make this reliably happen with WinBtrfs 1.3 on the latest Windows 10-1903... Basically, it happens whenever you try to change Windows security permissions on a bunch of files at once. I go into the Security tab of Properties for a high-level folder with tons of files in it, and add 'Full Control' access for a random user, and then apply it.

The error messages from DebugView are:

Btrfs ERR : flush_fcb : could not find INODE_ITEM for inode 375e8b9 in subvol 5
Btrfs ERR : do_write2 : flush_fcb returned c00000e5
Btrfs ERR : do_write : do_write2 returned c00000e5, dropping into readonly mode
Btrfs ERR : do_flush : do_write returned c00000e5

from btrfs.

Thanks. I can't reproduce it here on Windows 10 1511, which is all I have access to at the moment.

Two things...

• Is your filesystem clean? Can you please post the output of btrfs check on Linux?
• Is this definitely from my binaries, and not from ReactOS or elsewhere? The reason I ask is that the error messages should include the thread pointer, and there shouldn't be spaces around the colons.

from btrfs.

[root@shiny ~]# btrfs check --repair /dev/md126p6
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/md126p6
UUID: eb57a951-7723-4f5d-8b8e-a7cfb35b5600
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
No device size related problem found
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[4/7] checking fs roots
Can't get file name for inode 58316159, using '58316159' as fallback
Moving file '58316159' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 58316159
[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 1162739167232 bytes used, no error found
total csum bytes: 74101724
total tree bytes: 1438793728
total fs tree bytes: 1306574848
total extent tree bytes: 50233344
btree space waste bytes: 244120149
file data blocks allocated: 79716992339968
referenced 1152799862784

A lost inode, nothing major...

This is from your binaries I downloaded here on github just a few hours ago. I think the difference in error message is just because of how I have DebugView set up and how the text was formatted when I copied and pasted...

from btrfs.

No problem then, just making sure. I'll try and get a copy of 1903 and test there.

from btrfs.

There's a Perl script called btrfs-dump.pl in the tree - could you please download it and run it for /dev/md126p6? The output's almost certainly too big to send the whole thing, but if you search for "375e8b9,1" and send me the lines around there, it'd be a help.

I notice you're using an MD RAID device - how are you getting Windows to see this?

from btrfs.

The RAID device is Intel BIOS RAID, which works in both Windows and Linux. Linux handles it essentially as an MD RAID setup.

btrfs-dump-selected.txt

from btrfs.

It looks like the issue is that the file has a hard link, and we're opening the same inode twice. I can't reproduce it, but hopefully 2e063c8 should sort it.

from btrfs.

@elliotclee, can you please try using the version I've just released? It ought to fix your issue.

from btrfs.

from btrfs.

It happens in v1.7.1 when I make a 256 MB VHD, attach it as a drive letter, format it as BTRFS, and then copy over two 100 MB files. Trying to copy over a 50 MB or less file after those two have been copied results in a message stating that the disk is write protected.

from btrfs.

Closing old issue. Please log a new one if there is still a problem.

from btrfs.

I tried Winbtrfs with a new-bought disk. I had to compile mkbtrfs.exe myself, formatting with the release made it non-recognizable by Windows. I disabled COW, and tried to initiate a torrent download, the downloaded file was sizable, but heavily corrupted. Scrub did not recognize errors. Next, I tried to copy a file over from another disk unto a folder with COW enabled, the file actually copied fine and whole, but it messed up the disk, making it write-protected, scrub detects two corruptions, and balance says cyclic redundancy error. Since I don’t have access to Linux right now, I can’t diagnose further, and it seems Winbtrfs doesn't allow one to fix the drive. Re-formatting caused BSOD, I had to clean with diskpart.

Whatsmore, I tried once again, as soon I format with btrfs the disk is in 100% usage and gets very hot, and cannot unmount even though it’s empty. I don't know if the new Windows 20.04 is causing any of it. It’s kinda sad, I was looking forward to all those snapshots.

from btrfs.

@psisis - that does not sound like a healthy disk, brand new or no. Use gsmartcontrol to run a full test on it.

from btrfs.

@maharmstone
Thanks for the tip. Extended selftest passed several times. A quick surface test found no bad sectors. There's something strange going on, I don't really know what. I tried installing a game and it started fine, even with cow and lzo. But torrents really do not play nice, even with both disabled and full allocation, re-checking will always discover missing pieces. Right after trying the torrents (different clients) scrub discovers 200 unrecoverable checksum errors. (Did not force write-protection though)
btrfs check gives me

Opening filesystem to check...
Checking filesystem on /dev/sdb
UUID: 69814b6e-163a-490b-0830-5067017f40f5
[1/7] checking root items
checksum verify failed on 118276096 found E4E3BDB6 wanted 00000000
checksum verify failed on 118276096 found E4E3BDB6 wanted 00000000
checksum verify failed on 118276096 found E4E3BDB6 wanted 00000000
checksum verify failed on 118276096 found E4E3BDB6 wanted 00000000
bad tree block 118276096, bytenr mismatch, want=118276096, have=0
ERROR: failed to repair root items: Input/output error

When formatting I made sure to clean, no GPT and no existing volumes. If there's any use, I pasted inspect tree-node. Otherwise, it would mount on Linux. But I don't think it will ever work unfortunately.

from btrfs.