TL;DR version
On 12/11/2014 03:01 PM, Patrik Lundquist wrote:
Of course the filesystem is in a problematic state after the
conversion, even if it's not a bug. ~1.5TB of free space and yet out
of space and it can't be fixed with a balance. It might not be wrong
per se but it's very problematic from a user perspective.
The file system is not in a problematic state, you just don't understand
the state its in. It has ~1.5TB of space for files. Storing files is why
we have filesystems after all.
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdc1 2930265088 1402223656 1526389096 48% /mnt
There it is, ~1.5TB of available space.
That space is available for files. So no problem.
So it's not "out of space" at all. Go ahead and make a couple thousand
files of various sizes, you'll see. Lots of space.
Since it's not broken there is nothing for balance to "fix". The fact
that balance tells you it doesn't have enough space to juggle filesystem
bits HAS NOTHING TO DO with the file system's ability to store files.
You might as well be complaining that your hard disk is unfixable
because you don't have enough space to add another partition.
Apples and Polar Bears. The "out of space" is only a problem in your
head. At the same level of abstraction the EXT4 file system partition
was "out of space" before you started the conversion because all of the
partition was filled up with EXT4 structures.
No matter how many times you try to turn this into a "bug" it's just
_not_ a bug. Rewording it doesn't change the facts. The _file_ _system_
isn't "out of space" it's just filled its partition with BTRFS extents
enough to cause some extents to be skipped during balance.
Nothing to see here, move along. 8-)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
