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@xxxxxxxxxxxxxx> >>> --- >>> - 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:
signature.asc
Description: OpenPGP digital signature
