* Mixed inline and regular extents caused by btrfs/062 @ 2021-08-10 5:49 Qu Wenruo 2021-08-10 7:46 ` Nikolay Borisov 2021-08-23 14:43 ` Filipe Manana 0 siblings, 2 replies; 5+ messages in thread From: Qu Wenruo @ 2021-08-10 5:49 UTC (permalink / raw) To: linux-btrfs Hi, Although I understand current kernel can handle mixed inline extent with regular extent without problem, but the idea of mixing them is still making me quite unease. Thus I still go testing with modify btrfs-progs to detect such problem, and find out btrfs/062 can cause such mixed extents. Since it's not really causing any on-disk data corruption, but just an inconsistent behavior, I'm wondering do we really need to fix it. (This is also the only reason why subpage has disabled inline extent creation completely, just to prevent such problem). Any idea on whether we should "fix" the behavior? Thanks, Qu ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Mixed inline and regular extents caused by btrfs/062 2021-08-10 5:49 Mixed inline and regular extents caused by btrfs/062 Qu Wenruo @ 2021-08-10 7:46 ` Nikolay Borisov 2021-08-10 8:09 ` Qu Wenruo 2021-08-23 14:43 ` Filipe Manana 1 sibling, 1 reply; 5+ messages in thread From: Nikolay Borisov @ 2021-08-10 7:46 UTC (permalink / raw) To: Qu Wenruo, linux-btrfs On 10.08.21 г. 8:49, Qu Wenruo wrote: > Hi, > > Although I understand current kernel can handle mixed inline extent with > regular extent without problem, but the idea of mixing them is still > making me quite unease. > > Thus I still go testing with modify btrfs-progs to detect such problem, > and find out btrfs/062 can cause such mixed extents. > > Since it's not really causing any on-disk data corruption, but just an > inconsistent behavior, I'm wondering do we really need to fix it. > (This is also the only reason why subpage has disabled inline extent > creation completely, just to prevent such problem). > > Any idea on whether we should "fix" the behavior? What do you mean by mixed inline and regular extents? AFAICS inline extents are created when you write at the beginning of the file and the size of the write is less than the inline extent threshold? All subsequent writes are going to be regular extents. > > Thanks, > Qu > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Mixed inline and regular extents caused by btrfs/062 2021-08-10 7:46 ` Nikolay Borisov @ 2021-08-10 8:09 ` Qu Wenruo 2021-08-10 8:58 ` Qu Wenruo 0 siblings, 1 reply; 5+ messages in thread From: Qu Wenruo @ 2021-08-10 8:09 UTC (permalink / raw) To: Nikolay Borisov, linux-btrfs On 2021/8/10 下午3:46, Nikolay Borisov wrote: > > > On 10.08.21 г. 8:49, Qu Wenruo wrote: >> Hi, >> >> Although I understand current kernel can handle mixed inline extent with >> regular extent without problem, but the idea of mixing them is still >> making me quite unease. >> >> Thus I still go testing with modify btrfs-progs to detect such problem, >> and find out btrfs/062 can cause such mixed extents. >> >> Since it's not really causing any on-disk data corruption, but just an >> inconsistent behavior, I'm wondering do we really need to fix it. >> (This is also the only reason why subpage has disabled inline extent >> creation completely, just to prevent such problem). >> >> Any idea on whether we should "fix" the behavior? > > What do you mean by mixed inline and regular extents? I mean, one inode has both inlined extent and regular extent. There is an old btrfs-progs patch to detect such problems: https://patchwork.kernel.org/project/linux-btrfs/patch/20210504062525.152540-3-wqu@suse.com/ > AFAICS inline > extents are created when you write at the beginning of the file and the > size of the write is less than the inline extent threshold? All > subsequent writes are going to be regular extents. But with above patch, the following test cases can cause btrfs-check to report such mixed inline and regular extents: btrfs/004 btrfs/192 btrfs/195 btrfs/205 generic/269 (Haven't yet to check the reproducibility) Currently it won't hurt anyone, but I still don't think the mixed behavior is expected. Thanks, Qu > >> >> Thanks, >> Qu >> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Mixed inline and regular extents caused by btrfs/062 2021-08-10 8:09 ` Qu Wenruo @ 2021-08-10 8:58 ` Qu Wenruo 0 siblings, 0 replies; 5+ messages in thread From: Qu Wenruo @ 2021-08-10 8:58 UTC (permalink / raw) To: Nikolay Borisov, linux-btrfs On 2021/8/10 下午4:09, Qu Wenruo wrote: > > > On 2021/8/10 下午3:46, Nikolay Borisov wrote: >> >> >> On 10.08.21 г. 8:49, Qu Wenruo wrote: >>> Hi, >>> >>> Although I understand current kernel can handle mixed inline extent with >>> regular extent without problem, but the idea of mixing them is still >>> making me quite unease. >>> >>> Thus I still go testing with modify btrfs-progs to detect such problem, >>> and find out btrfs/062 can cause such mixed extents. >>> >>> Since it's not really causing any on-disk data corruption, but just an >>> inconsistent behavior, I'm wondering do we really need to fix it. >>> (This is also the only reason why subpage has disabled inline extent >>> creation completely, just to prevent such problem). >>> >>> Any idea on whether we should "fix" the behavior? >> >> What do you mean by mixed inline and regular extents? > > I mean, one inode has both inlined extent and regular extent. > > There is an old btrfs-progs patch to detect such problems: > > https://patchwork.kernel.org/project/linux-btrfs/patch/20210504062525.152540-3-wqu@suse.com/ > > > >> AFAICS inline >> extents are created when you write at the beginning of the file and the >> size of the write is less than the inline extent threshold? All >> subsequent writes are going to be regular extents. > > But with above patch, the following test cases can cause btrfs-check to > report such mixed inline and regular extents: > > btrfs/004 > btrfs/192 > btrfs/195 > btrfs/205 > generic/269 Above two tests are almost 100% reproducible of such mixed extents, especially btrfs/205 is pretty short tests. I guess a fix would be easier to understand the problem. Thanks, Qu > > (Haven't yet to check the reproducibility) > > Currently it won't hurt anyone, but I still don't think the mixed > behavior is expected. > > Thanks, > Qu >> >>> >>> Thanks, >>> Qu >>> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Mixed inline and regular extents caused by btrfs/062 2021-08-10 5:49 Mixed inline and regular extents caused by btrfs/062 Qu Wenruo 2021-08-10 7:46 ` Nikolay Borisov @ 2021-08-23 14:43 ` Filipe Manana 1 sibling, 0 replies; 5+ messages in thread From: Filipe Manana @ 2021-08-23 14:43 UTC (permalink / raw) To: Qu Wenruo; +Cc: linux-btrfs On Tue, Aug 10, 2021 at 8:06 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote: > > Hi, > > Although I understand current kernel can handle mixed inline extent with > regular extent without problem, but the idea of mixing them is still > making me quite unease. > > Thus I still go testing with modify btrfs-progs to detect such problem, > and find out btrfs/062 can cause such mixed extents. > > Since it's not really causing any on-disk data corruption, but just an > inconsistent behavior, I'm wondering do we really need to fix it. > (This is also the only reason why subpage has disabled inline extent > creation completely, just to prevent such problem). > > Any idea on whether we should "fix" the behavior? We had a discussion about this not long ago: https://lore.kernel.org/linux-btrfs/20210506070458.168945-1-wqu@suse.com/ And yes, as you found out, it's quite easy to trigger scenarios of an inline extent followed by non-inline extents. Both fsstress and fsx can trigger it often, plus I remember writing test cases that explicitly exercise those scenarios to verify that either extent cloning works as expected or send/receive, like in btrfs/205 for example. Yes, there's the case triggered by fallocate, but also the case triggered by a compressed inline extent, representing PAGE_SIZE bytes of data, followed by other extents. This case was discussed in the past too: https://lore.kernel.org/linux-btrfs/20180302052254.7059-3-wqu@suse.com/ Currently this one isn't triggered anymore, but that's due to a temporary regression in 5.14-rcs reported yesterday by Zygo, that results in never having compressed inline extents. I still don't consider it a problem. The code paths have been exercised for years, reads, writes, cloning, send/receive, etc, all work as expected as far as I know. Having the inline extent always brings a performance benefit when reading its data, so I don't see any advantage in changing the behaviour - doesn't make the code faster, shorter or easy to read/maintain. Thanks. > > Thanks, > Qu -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.” ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-08-23 14:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-10 5:49 Mixed inline and regular extents caused by btrfs/062 Qu Wenruo 2021-08-10 7:46 ` Nikolay Borisov 2021-08-10 8:09 ` Qu Wenruo 2021-08-10 8:58 ` Qu Wenruo 2021-08-23 14:43 ` Filipe Manana
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.