On Sun, Mar 06, 2016 at 06:43:46AM +0000, Duncan wrote: > Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted: > > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote: > >> Something is happening with the usage of this file system that's out of > >> the ordinary. This is the first time I've seen such a large amount of > >> unused metadata allocation. And then for it not only fail to balance, > >> but for the allocation amount to increase is a first. > > > > It is just a root filesystem of a workstation running Debian Linux, in > > daily use, with daily snapshots of the system, and ten-minute-increment > > snapshots of /home, with no cleanup happening for a few months. > > > >> So understanding the usage is important to figuring out what's > >> happening. I'd file a bug and include as much information on how the > >> fs got into this state as possible. And also if possible make a > >> btrfs-image using the proper flags to blot out the filenames for > >> privacy. > > Now you're homing in on what I picked up on. There's something very > funky about that metadata, 100+ GiB of metadata total, only just over 2 > GiB metadata used, and attempts to balance it don't help with the spread > between the two at all, only increasing the total metadata, if anything, > but still seem to complete without error. There's gotta be some sort of > bug going on there, and I'd /bet/ it's the same one that's keeping full > balances from working, as well. I don't understand a single word of this, but you seem to understand it. Good. > > OK, this question's out of left field, but it's the only thing (well, > /almost/ only, see below) I've seen do anything /remotely/ like that: > > Was the filesystem originally created as a convert from ext*, using btrfs- > convert? If so, was the ext2_saved or whatever subvolume removed, and a > successful defrag and balance completed at that time? I have dug aroud in my auth.logs, and thanks to my not working in a root shell but using sudo for every single command I can say that the filesystem was created on September 1, 2015, so it is not _this_ old, and snapshot.debian.net tells me that Debian unstable had btrfs-tools 4.1.2 uploaded on August 31, so i guess that the filesystem was either created by the 4.0 version we had since May 2015 or by the brand new 4.1.2. And it was a mkfs.btrfs with no special options. I suspected this since I would probably not have made an ext4 filesystem of 300 GB in size. Back in the ext4 days, I usually made /, /usr, /var, /home and /boot their own filesystems. > Tho AFAIK there was in addition a very narrow timeframe in which a bug in > mkfs.btrfs would create invalid btrfs'. That was with btrfs-progs 4.1.1, > released in July 2015, with an urgent bugfix release 4.1.2 in the same > month to fix the problem, so the timeframe was days or weeks. Debian is chastized for their allegedly quirky release schedules even in this thread, I usually ignore that, but this time a smile comes to my face when I say that btrfs-progs 4.1.1 was never packaged in Debian, hence we're clear of this bug here. We went from 4.0 straight to 4.1.2. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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
