Re: ENOSPC errors during raid1 rebalance

[Duncan <1i5t5.duncan@cox.net>]

Michael Russo posted on Wed, 05 Mar 2014 22:13:10 +0000 as excerpted:

> Chris Murphy <lists <at> colorremedies.com> writes:
> 
>> You could also try a full defragment by specifying -r on the mount
>> point with a small -t value to effectively cause everything to be
>> subject to defragmenting. If this still doesn't permit soft rebalance,
>> then maybe filefrag can find files that have more than 1 extent and
>> just copy them (make duplicates, delete the original). Any copy will be
>> allocated into chunks with the new profile.
> 
> I would think so too.  But it doesn't seem to be happening.
> Here is an example with one file:
> 
> root@ossy:/mymedia# filefrag output.wav output.wav: 2 extents found
> root@ossy:/mymedia# /usr/src/btrfs-progs/btrfs fi de -t 1
> /mymedia/output.wav root@ossy:/mymedia# filefrag output.wav output.wav:
> 2 extents found
> 
> btrfs does not defrag the file. And copying the file usually doesn't
> defrag it either:
> 
> root@ossy:/mymedia# cp output.wav output.wav.bak root@ossy:/mymedia#
> filefrag output.wav.bak output.wav.bak: 2 extents found
> 
> I even tried copying a large file to another filesystem (/dev/shm),
>  removing the original, and copying it back, and more often than not
> it still had more than 1 extent.

This was covered in one thread recently, but looking back in this one I 
didn't find it covered here, so...

What are your mount options?  Do they include compress and/or compress-
force?  Because filefrag doesn't understand btrfs compression yet and 
counts each 128 KiB (I believe) compression block as a separate extent.  
I'm not sure whether that's 128 KiB pre-compression or post-compression 
size, and I'm not even positive it's 128 KiB, but certainly, if the file 
is large enough and btrfs is compressing it, filefrag will false-positive 
report multiple extents.  That's a known issue with it ATM.

Meanwhile, there's ongoing work to teach filefrag about btrfs compression 
so it can report fragmentation accurately, but from what I've read 
they're working on a general kernel-VFS-level API for that so the same 
general API can be used by other filesystems, and getting proper 
agreement on that API, and having both the kernel and filefrag implement 
it isn't a simple single-kernel-cycle project.  There's a lot of 
filesystems other than btrfs that could potentially use this sort of 
thing, and getting a solution that will work well for all of them is hard 
work, both technically and politically.  But once it's implemented, /
correctly/, the entire Linux kernel filesystem space will benefit, just 
as btrfs is getting the benefit of the filefrag tool that ships with 
e2fsprogs, and the filesystem testing that ships as xfstests. =:^)

But if you're not using compression, /that/ can't explain it...

-- 
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