From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com ([74.125.82.49]:37053 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757742AbcAKHzQ (ORCPT ); Mon, 11 Jan 2016 02:55:16 -0500 Received: by mail-wm0-f49.google.com with SMTP id f206so254422161wmf.0 for ; Sun, 10 Jan 2016 23:55:15 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20160109202659.GC6060@carfax.org.uk> From: "cheater00 ." Date: Mon, 11 Jan 2016 08:54:55 +0100 Message-ID: Subject: Re: 6TB partition, Data only 2TB - aka When you haven't hit the "usual" problem To: Chris Murphy Cc: Henk Slager , Btrfs BTRFS , Hugo Mills Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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 . 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 . 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 wrote: >>> On Sun, Jan 10, 2016 at 4:47 PM, cheater00 . wrote: >>>> On Sun, Jan 10, 2016 at 3:14 PM, Henk Slager 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