Fajar A. Nugraha wrote:
> On Thu, Dec 29, 2011 at 4:39 PM, Li Zefan <l...@cn.fujitsu.com> wrote:
>> Fajar A. Nugraha wrote:
>>> On Wed, Dec 28, 2011 at 11:57 PM, Martin Steigerwald
>>> <mar...@lichtvoll.de> wrote:
>>>> But BTRFS does not:
>>>>
>>>> merkaba:~> fstrim -v /
>>>> /: 4431613952 bytes were trimmed
>>>> merkaba:~> fstrim -v /
>>>> /: 4341846016 bytes were trimmed
>>>
>>> .... and apparently it can't trim everything. Or maybe my kernel is
>>> just too old.
>>>
>>>
>>> $ sudo fstrim -v /
>>> 2258165760 Bytes was trimmed
>>>
>>> $ df -h /
>>> Filesystem Size Used Avail Use% Mounted on
>>> /dev/sda6 50G 34G 12G 75% /
>>>
>>> $ mount | grep "/ "
>>> /dev/sda6 on / type btrfs (rw,noatime,subvolid=258,compress-force=lzo)
>>>
>>> so only about 2G out of 12G can be trimmed. This is on kernel 3.1.4.
>>>
>>
>> That's because only free spaces in block groups will be trimmed. Btrfs
>> allocates space from block groups, and when there's no space availabe,
>> it will allocate a new block group from the pool. In your case there's
>> ~10G in the pool.
>
> Thanks for your response.
>
>>
>> You can do a "btrfs fi df /", and you'll see the total size of existing
>> block groups.
>
> $ sudo btrfs fi df /
> Data: total=43.47GB, used=31.88GB
> System, DUP: total=8.00MB, used=12.00KB
> System: total=4.00MB, used=0.00
> Metadata, DUP: total=3.25GB, used=619.88MB
This is DUP, so the actual physical size is (3.25 * 2) = 6.5G
> Metadata: total=8.00MB, used=0.00
>
> That should mean existing block groups is at least 46GB, right? In
so the sum is 50G.
> which case my pool (a 50G partition) should only have about 4GB of
> space not allocated to block groups. The numbers don't seem to match.
>
The pool has been emptied, so there're other reasons that you had only
~2GB trimmed, and the possible reason is fstrim in btrfs is buggy.
I sent a fix weeks ago, which is not merged yet:
http://marc.info/?l=linux-btrfs&m=132212530410572&w=2
>>
>> You can empty the pool by:
>>
>> # dd if=/dev/zero of=/mytmpfile bs=1M
>>
>> Then release the space (but it won't return back to the pool):
>>
>> # rm /mytmpfile
>> # sync
>
> Is there a bad side effect of doing so? For example, since all free
> space in the pool would be allocated to data block group, would that
> mean my metadata block group is capped at 3.25GB?
You can config the ratio of data block groups and metadata block groups
via "metadata_ratio=" mount option.
> Or would some data
> block group can be converted to metadata, and vice versa?
>
This won't happen. Also empty block groups won't be reclaimed, but it's
in TODO list.
--
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
