Re: About the behavior of inline extent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Apr 9, 2017, at 11:27 PM, Qu Wenruo <quwenruo@xxxxxxxxxxxxxx> wrote:
> 
> Hi,
> 
> Recent btrfs/137 test case makes me wonder what's the designed behavior of btrfs inline data extent.
> 
> The current behavior in fact is quite a chaos.
> We need a standard of how inline extent should behave.
> 
> 1) max_inline limit
>   The problem of current max_inline is, it's never clear what it is
>   limiting.
> 
>   For example, we don't allow page sized inline extent if not
>   compressed.
>   But we allow page sized inline extent if it's compressed.
>   Is it just limiting size after compression?
>   What if we really want to limit size before compression?
> 

max_inline is for the actual space on disk.  Compression takes up less space, therefore you can fit bigger actual data into the inline area.

> 2) inline extent condition
>   Is inline extent allowed if we have following regular extent?
> 
>   For plain extent, prealloc can cause regular extent to co-exist with
>   inlined one.
>   While normal write will only convert inlined extent to regular one.
> 
>   While for compressed extent, it can co-exist with regular extent, by
>   # xfs_io -f -c "pwrite 0 4k" -c sync -c "pwrite 4k 16k" /mnt/btrfs/file
> 
>   So which is the correct behavior?
>   Personally I think we should not allow co-exist, as it's already
>   causing a lot of fixes for it, that's to say neither current
>   behavior is correct.
> 

Historically we didn't have [inline][regular] because inline was always < block size, so any change to the inline extent to extend it resulted in a regular extent.  Obviously that changed with fallocate, so it is perfectly reasonable to have [inline][regular extent]

> 3) inline extent and fallocate
>   For inline extent, as long as we are calling fallocate inside the
>   page size, only the isize is expanded.
> 
>   Only beyond page size, we get prealloc extents.
>   (However inlined extent is still here, not converted)
> 
>   What's the designed behavior? Convert inline to regular or just
>   leave it as is?

Leave it.  fallocate doesn't change anything about existing regular extents.  Calling fallocate on a range completely inside of a regular extent does nothing, why would this change with an inline extent?  Now past the inline extent you get a new extent, exactly the same behavior as a regular extent.  Thanks,

Josef

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html





[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux