After the fsck, the Data segment is being resized correctly. It would seem to me that the fact Data was 2TB when this bug transpired was just a coincidence. Perhaps this line: "BTRFS info (device sdc1): The free space cache file (2159324168192) is invalid. skip it" should not be "info" but an error, and should instruct the user to fsck the file system. I have requested an account on the btrfs wiki in order to add this info to: https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21 On Mon, Jan 11, 2016 at 7:24 AM, cheater00 . <cheater00@xxxxxxxxx> wrote: > When re-mounting now, this line was not present any more in dmesg: > "BTRFS info (device sdc1): The free space cache file (2159324168192) > is invalid. skip it" > > dmesg only showed: > "[216798.144518] BTRFS info (device sdc1): disk space caching is enabled" > > On Mon, Jan 11, 2016 at 7:07 AM, cheater00 . <cheater00@xxxxxxxxx> wrote: >> Here is the fsck log: >> >> # btrfs check /dev/sdc1 >> Checking filesystem on /dev/sdc1 >> UUID: b397b7ef-6754-4ba4-8b1a-fbf235aa1cf8 >> checking extents >> checking free space cache >> checking fs roots >> checking csums >> checking root refs >> found 2178647877626 bytes used err is 0 >> total csum bytes: 2123923832 >> total tree bytes: 3749871616 >> total fs tree bytes: 645742592 >> total extent tree bytes: 680394752 >> btree space waste bytes: 284237552 >> file data blocks allocated: 2178788139008 >> referenced 2173089497088 >> btrfs-progs v4.2.1 >> >> On Mon, Jan 11, 2016 at 1:24 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >>> On Sun, Jan 10, 2016 at 4:47 PM, cheater00 . <cheater00@xxxxxxxxx> wrote: >>>> On Sun, Jan 10, 2016 at 3:14 PM, Henk Slager <eye1tm@xxxxxxxxx> wrote: >>> >>>> buggy fs ("Media"): >>>> Data, single: total=1.98TiB, used=1.98TiB >>>> System, DUP: total=8.00MiB, used=240.00KiB >>>> System, single: total=4.00MiB, used=0.00B >>>> Metadata, DUP: total=5.50GiB, used=3.49GiB >>>> Metadata, single: total=8.00MiB, used=0.00B >>>> GlobalReserve, single: total=512.00MiB, used=0.00B >>>> >>>>> What you could try is to create an image+'copy' of the fs with >>>>> btrfs-image just after you get ENOSPC abd then do various tests with >>>>> that (make sure unmount or even better unplug the physical hdd!). Like >>>>> mounting and then try to add a file, convert all metadata + system >>>>> from dup to single and then try to add a file. It all doesn't give >>>>> real space, but it might give hints to what could be wrong. >>>> >>>> I can't do that because I would have to buy an extra disk which is 300 euro. >>> >>> You have 4TB unused on that disk. You could shrink the fs to ~3TB, and >>> then change partition size to match and create a 2nd partition with >>> whatever FS you want as the target for btrfs-image. >>> >>> After that, migrate your data from the broken fs to the new one. If >>> you use Btrfs for the new volume on that 2nd partition you can use >>> btrfs send-receive for this. After it's successful, you can wipefs the >>> 1st partition, and then add it as an additional device to the new >>> volume. >>> >>> -- >>> Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
