Re: [RFC][PATCH] btrfs: add an autodefrag property

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1649 bytes --]



On 2020/7/18 上午7:58, Josef Bacik wrote:
> On 7/17/20 7:46 PM, Qu Wenruo wrote:
>>
>>
>> On 2020/7/18 上午4:42, Josef Bacik wrote:
>>> Autodefrag is very useful for somethings, like the 9000 sqllite files
>>> that Firefox uses, but is way less useful for virt images.
>>> Unfortunately this is only available currently as a whole mount option.
>>> Fix this by adding an "autodefrag" property, that users can set on a per
>>> file or per directory basis.  Thus allowing them to control where
>>> exactly the extra write activity is going to occur.
>>>
>>> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
>>> ---
>>> - This is an RFC because I want to make sure we're ok with this
>>> before I go and
>>>    add btrfs-progs support for this.  I'm not married to the name or
>>> the value,
>>>    but I think the core goal is valuable.
>>
>> The idea looks pretty good to me.
>>
>> Although it would be much more convincing to bring some real-world micro
>> bench to show the benefit.
>>
> 
> The same benefit as what existed originally for autodefrag, firefox
> isn't unusably slow on spinning rust.
> 
>>
>> However I still have a concern related to defrag.
>> Since it's on-disk flag, thus can be inherited by snapshot, then what
>> would happen if an auto-defrag inode get snapshotted.
>>
>> Would any write to the auto-defrag inode in new snapshot break the space
>> saving?
> Sure but that's the case for all defrag, and this is in fact better than
> mount -o autodefrag because you can limit the damage.  Thanks,

That's right. So no problem at all then.

Thanks,
Qu

> 
> Josef


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]