Can't create\copy files larger than certain size about btrfs HOT 14 CLOSED

That'd be my guess too. How much free space does it say that you have? Does a balance help?

from btrfs.

I believe this is the case. I've just deleted 707MB file from my btrfs partition and was able to copy a new 702MB file but on the second one system asked me about free space. And that partition has an around 50GB free space out of 200GB in overall. But it's actually pretty weird: the partition must be very fragmented to have only 58MB sequential free space. Is there any way to check it?

I wasn't able to start balance with c000007f error, and partition went read-only. Will try to reboot and do the same under linux.

from btrfs.

What does btrfs fi usage say under Linux?

from btrfs.

Will tell in a couple minutes. I've done balancing under Linux, it went fine. After that I was able to write 4 4GB files. But when I've tried to delete them the partition became read-only. So another reboot :)

from btrfs.

The partition became faulty, it can't be mounted under Linux anymore with 'failed to read chunk root'. Windows shows it as a non-formated drive and offers to format it.

It's a pity :)
Seems that the only option is to try btrfs rescue chunk-recover. But it says there are 6 unrecoverable chunks.

from btrfs.

Sorry, I don't know what the issue is then... I've not yet got round to testing on volumes which are absolutely full, it might be that you've run into a bug there. I know there were issues with this on Linux for quite some time.

from btrfs.

@maharmstone don't worry, I knew what I am doing when used experimental software. I've made a copy of the most important data (not all, but it's my fault).

Ok, it seems that I the partition is lost. Even btrfs check --repair can't fix it. Just to describe the situation:
I wanted to try switch to Windows because my new hardware doesn't work well enough with Linux. Firstly I thought that I will need to copy all of my working data (around 100+GB) to windows partition but then I found this project and decide to give it a chance: leave data on its place and use it from there - just to have a change go back if something won't work well on Windows.
So:

1. I've installed the latest version of WinBtrfs and reboot. After that I saw btrfs partition and it contents.
2. I've made mapping Windows user -> Linux user and reboot.
3. I've tried to get an access to btrfs partition from WSL - unsuccessfully as described in another issue.
4. I've tried to change My documents path to my documents on btrfs. At this step I found that I can't copy large files and made some experiments. By the method of thumb I found that I can't copy files lager than 58MB (see above).
5. I've tried to rebalance partition from Windows (hopefully made a copy of the important data first) but got an error and partition became read-only.
6. I've booted to Linux and found partition unmountable with an error but fixed it with clear log (edited: a went into initramfs failsafe mode, an error was something like "BTRFS: failed to read log tree" and I fixed it with btrfs-zero-log if I remember correctly).
7. After that I've rebooted to Linux again, it loaded into multi-user mode, scrubbed data without any issues and successfully balanced partition.
8. Then I've switched back to Windows and found that I can copy more than 4GB file to the btrfs partition. Just to verify I copied the same file 4 times (by renaming the copied ones). But when I've tried to delete these 4 files I got an error and partition became read only.

When I booted into Linux I found partition unmountable with 'failed to read chunk root'.

I've tried to recover tree with 'btrfs rescue chunk-recover' but it didn't help. btrfs check --repair fixed a number of errors but not all - still getting one error on inode 255 (if I remember correctly) and 'failed to read chunk root' on mount. Now I left that partition as it is for a while. If I can share any useful data just let me know: not to repair partition (I believe it's deadly dead) but to help with your project - it's very valuable and useful.

from btrfs.

Thank you. Points 6, 7, and 8 - is one "Linux" there supposed to read "Windows"?

Do you get the same error if you try to mount the partition as readonly under Linux?

If you would, could you please send me:

• The output of btrfs check
• What gets posted to dmesg when you try to mount
• The output of btrfs-debug-tree -t 1 and btrfs-debug-tree -t 3

Thanks

from btrfs.

@maharmstone Sorry for this mess, here is the correct (edited) text:

6. I've booted to Linux and found partition unmountable with an error but fixed it with clear log (edited: a went into initramfs failsafe mode, an error was something like "BTRFS: failed to read log tree" and I fixed it with btrfs-zero-log if I remember correctly).
7. After that I've rebooted to Linux again, it loaded into multi-user mode, scrubbed data without any issues and successfully balanced partition.
8. Then I've switched back to Windows and found that I can copy more than 4GB file to the btrfs partition. Just to verify I copied the same file 4 times (by renaming the copied ones). But when I've tried to delete these 4 files I got an error and partition became read only.

And now I must say that I feel like a savage in front of new tech ("it's a magic!"): I've booted with Fedora Live drive to answer your question and found that I can mount partition. Don't know what's happened. I still get errors on "btrfs check" (see below) but CAN mount partition both in Live CD and during old linux system boot (I wasn't before).

So I have 3 options:

1. Your driver has repair mechanism
2. I actually repaired the partition with btrfs check but didn't reboot after that and it didn't want to remount (though I remember I did reboot and that partition became as unformated when I booted in Windows after repair)
3. The magic is around us and we must cast aside all tech and return to nature.

Ok, now some facts:

1. If you remember, I told that I've copied 4 large files after rebalance (p.8) and then tried to delete them. Now I can see 2 of them (so 2 was deleted and 2 - didn't).
2. I can copy large files to the partition (so it seems to work ok).
3. btrfs fi usage under Linux (now):

[liveuser@localhost vlad]$ sudo btrfs fi usage /mnt
Overall:
    Device size:                 200.00GiB
    Device allocated:            156.03GiB
    Device unallocated:           43.97GiB
    Device missing:                  0.00B
    Used:                        153.88GiB
    Free (estimated):             44.91GiB      (min: 44.91GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,single: Size:153.00GiB, Used:152.06GiB
   /dev/nvme0n1p4        153.00GiB

Metadata,single: Size:3.00GiB, Used:1.82GiB
   /dev/nvme0n1p4          3.00GiB

System,single: Size:32.00MiB, Used:48.00KiB
   /dev/nvme0n1p4         32.00MiB

Unallocated:
   /dev/nvme0n1p4         43.97GiB

4. btrfs check:

[liveuser@localhost ~]$ sudo btrfs check /dev/nvme0n1p4
Checking filesystem on /dev/nvme0n1p4
UUID: eb511db0-07b8-478f-a8fa-8888da2dc0d8
checking extents
checking free space cache
checking fs roots
root 5 root dir 256 error
root 5 inode 256 errors 200, dir isize wrong
found 165232377856 bytes used err is 1
total csum bytes: 152309552
total tree bytes: 1956118528
total fs tree bytes: 1706360832
total extent tree bytes: 84393984
btree space waste bytes: 342617200
file data blocks allocated: 287409909760
 referenced 161271017472

5. dmesg (during installed system boot):

vlad@wind ~ $ dmesg | grep BTRFS
[    2.687828] BTRFS: device label fedora_wind devid 1 transid 258403 /dev/nvme0n1p4
[    3.779513] BTRFS info (device nvme0n1p4): disk space caching is enabled
[    3.779514] BTRFS info (device nvme0n1p4): has skinny extents
[    3.781226] BTRFS info (device nvme0n1p4): bdev /dev/nvme0n1p4 errs: wr 0, rd 0, flush 0, corrupt 3945, gen 0
[    3.805281] BTRFS info (device nvme0n1p4): detected SSD devices, enabling SSD mode
[    4.316452] BTRFS info (device nvme0n1p4): disabling disk space caching
[    4.316455] BTRFS info (device nvme0n1p4): force clearing of disk cache

I'm pretty confused with corrupt 3945 part. Can find what does it mean but btrfs scrub found 0 errors.

Forgot to run btrfs-debug-tree -t 1 and btrfs-debug-tree -t 3, will do it in a few minutes.

from btrfs.

I definitely need to clear my karma :-D

I've tried to reboot to linux to check btrfs-debug-tree but wasn't able to do it. So before reboot I copied a big file to the btrfs partition.

Now in Linux I get next errors:
dmesg after mount try:

[liveuser@localhost ~]$ dmesg | grep BTRFS
[    5.364615] BTRFS: device label fedora_wind devid 1 transid 258438 /dev/nvme0n1p4
[  120.015924] BTRFS info (device nvme0n1p4): disk space caching is enabled
[  120.015925] BTRFS info (device nvme0n1p4): has skinny extents
[  120.017580] BTRFS error (device nvme0n1p4): invalid chunk sectorsize 0
[  120.017593] BTRFS error (device nvme0n1p4): failed to read chunk tree: -5
[  120.042208] BTRFS: open_ctree failed

other commands, including btrfs-debug-tree and btrfs check, like this:

[liveuser@localhost ~]$ sudo btrfs-debug-tree -t 1 /dev/nvme0n1p4
btrfs-progs v4.6.1
ERROR: invalid chunk sectorsize 0
ERROR: Metadata checksums match, but it has an invalid chunk, 
volumes.c:2004: btrfs_read_chunk_tree: Assertion `ret` failed.
btrfs-debug-tree(+0x2134a)[0x56479cf4534a]
btrfs-debug-tree(btrfs_read_chunk_tree+0x2f6)[0x56479cf48896]
btrfs-debug-tree(btrfs_setup_chunk_tree_and_device_map+0xfb)[0x56479cf360ab]
btrfs-debug-tree(+0x122aa)[0x56479cf362aa]
btrfs-debug-tree(open_ctree_fs_info+0x8c)[0x56479cf364cc]
btrfs-debug-tree(cmd_inspect_dump_tree+0x33e)[0x56479cf5b17e]
btrfs-debug-tree(main+0x3b)[0x56479cf2c9ab]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f4b60304401]
btrfs-debug-tree(_start+0x2a)[0x56479cf2c9fa]

But I can read data on this partition under Windows! I even tried to reboot to Linux again - nope, doesn't work. In Windows it works.

So there IS some kind of incompatibility between current Linux version and your win implementation. If you need more info, just let me know.

from btrfs.

Thank you. I know from past experience that the Linux driver is a lot less tolerant of faults than my driver, but I'm still a little confused. It looks like the balance might be the source of at least some of your problems, but I've put some fixes for this in the latest release.

Are you certain your disk is okay, by the way? The message "corrupt 3945" means that in the past it's had 3945 checksum errors. Would you mind doing a full test in smartd? I imagine you'd probably want to know yourself...

from btrfs.

I have Toshiba THNSN5512GPU7 NVMe SSD, and it doesn't have any self-test routines. But SMART attributes are OK, 100% spare area and 98% of endurance still available.

from btrfs.

I am getting the error mentioned by the OP in Windows 10 x64 when I try to copy/move files from another partiton to it/create files of a certain size when there's 10-15% free space remaining in the BTRFS partition. I am using 1.7.3 of the driver.

from btrfs.

@ElpizoZ - not a bug - that's how the metadata chunks work.

I'm closing this because it's so old - please @vheathen relog if you still have issues.

from btrfs.