Robert White posted on Wed, 10 Dec 2014 04:17:50 -0800 as excerpted: >> BTRFS info (device sdc1): relocating block group 1821099687936 flags 1 >> BTRFS error (device sdc1): allocation failed flags 1, wanted 2013265920 >> BTRFS: space_info 1 has 4773171200 free, is not full BTRFS: space_info >> total=1494648619008, used=1489775505408, pinned=0, reserved=99700736, >> may_use=2102390784, readonly=241664 > > So it was looking for a single chunk 2013265920 bytes long and it > couldn't find one because all the spaces were smaller and there was no > room to make a new suitable space. > > The problem is that it wanted 2013265920 bytes and while the system as a > whole had no way to satisfy that desire. It asked for something just shy > of two gigs as a single extent. That's a tough order on a full platter. > > Since your entire free size is 2102390784 that is an attempt to allocate > about 80% of your free space as one contiguous block. That's never going > to happen. 8-) > > I don't even know if 2GiB is normally a legal size for an extent. My > understanding is that data is allocated in 1G chunks, so I'd expect all > extents to be smaller than 1G. On native btrfs, an extent must fit within the 1 GiB data chunk size, with extents inherited from an ext* conversion being an obvious non- native exception. I hadn't looked at the actual output, but that confirms my earlier suspicion, that after the ext* saved subvolume delete, the defrag somehow missed at least one file > 1 GiB with a "super-extent" also > 1 GiB in size. >From there... I've never used it but I /think/ btrfs inspect-internal logical-resolve should let you map the 182109... address to a filename. >From there, moving that file out of the filesystem and back in should eliminate that issue. Assuming no snapshots still contain the file, of course, and that the ext* saved subvolume has already been deleted. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
