On Fri, Jun 03, 2022 at 09:09:06AM -0400, Mike Snitzer wrote:
> I think the point was to keep the biosets embedded in struct
> mapped_device to avoid any possible cacheline bouncing due to the
> bioset memory being disjoint.
Probably.
> But preserving that micro-optimization isn't something I've
On Thu, Jun 02 2022 at 4:12P -0400,
Christoph Hellwig wrote:
> On Wed, Jun 01, 2022 at 10:13:34AM -0400, Mike Snitzer wrote:
> > Please take the time to look at the code and save your judgement until
> > you do. That said, I'm not in love with the complexity of how DM
> > handles bioset
On Wed, Jun 01, 2022 at 10:13:34AM -0400, Mike Snitzer wrote:
> Please take the time to look at the code and save your judgement until
> you do. That said, I'm not in love with the complexity of how DM
> handles bioset initialization. But both you and Jens keep taking
> shots at DM for doing
On 6/2/22 2:12 AM, Christoph Hellwig wrote:
> On Wed, Jun 01, 2022 at 10:13:34AM -0400, Mike Snitzer wrote:
>> Please take the time to look at the code and save your judgement until
>> you do. That said, I'm not in love with the complexity of how DM
>> handles bioset initialization. But both you
On Wed, Jun 01 2022 at 2:04P -0400,
Christoph Hellwig wrote:
> On Tue, May 31, 2022 at 02:58:00PM -0400, Mike Snitzer wrote:
> > Yes, we need the above to fix the crash. Does it also make sense to
> > add this?
>
> Can we just stop treating bio_sets so sloppily and make the callers
> handle
On Tue, May 31, 2022 at 02:58:00PM -0400, Mike Snitzer wrote:
> Yes, we need the above to fix the crash. Does it also make sense to
> add this?
Can we just stop treating bio_sets so sloppily and make the callers
handle their lifetime properly? No one should have to use
bioset_initialized (or
On Wed, Jun 01, 2022 at 12:08:57AM -0600, Jens Axboe wrote:
> Yes, that was my point in the previous email - get rid of
> bioset_initialized() and just fixup dm, which is the only user of it.
> There really should be no need to have this kind of conditional checking
> and initialization.
dm and
On 6/1/22 12:04 AM, Christoph Hellwig wrote:
> On Tue, May 31, 2022 at 02:58:00PM -0400, Mike Snitzer wrote:
>> Yes, we need the above to fix the crash. Does it also make sense to
>> add this?
>
> Can we just stop treating bio_sets so sloppily and make the callers
> handle their lifetime
On 5/31/22 1:49 PM, Mike Snitzer wrote:
> On Tue, May 31 2022 at 3:00P -0400,
> Jens Axboe wrote:
>
>> On 5/31/22 12:58 PM, Mike Snitzer wrote:
>>> On Sun, May 29 2022 at 8:46P -0400,
>>> Jens Axboe wrote:
>>>
On 5/28/22 6:17 PM, Matthew Wilcox wrote:
> Not quite sure whose bug this
On Tue, May 31 2022 at 3:00P -0400,
Jens Axboe wrote:
> On 5/31/22 12:58 PM, Mike Snitzer wrote:
> > On Sun, May 29 2022 at 8:46P -0400,
> > Jens Axboe wrote:
> >
> >> On 5/28/22 6:17 PM, Matthew Wilcox wrote:
> >>> Not quite sure whose bug this is. Current Linus head running xfstests
> >>>
On 5/31/22 12:58 PM, Mike Snitzer wrote:
> On Sun, May 29 2022 at 8:46P -0400,
> Jens Axboe wrote:
>
>> On 5/28/22 6:17 PM, Matthew Wilcox wrote:
>>> Not quite sure whose bug this is. Current Linus head running xfstests
>>> against ext4 (probably not ext4's fault?)
>>>
>>> 01818 generic/250
On Sun, May 29 2022 at 8:46P -0400,
Jens Axboe wrote:
> On 5/28/22 6:17 PM, Matthew Wilcox wrote:
> > Not quite sure whose bug this is. Current Linus head running xfstests
> > against ext4 (probably not ext4's fault?)
> >
> > 01818 generic/250 run fstests generic/250 at 2022-05-28 23:48:09
On 5/28/22 6:17 PM, Matthew Wilcox wrote:
> Not quite sure whose bug this is. Current Linus head running xfstests
> against ext4 (probably not ext4's fault?)
>
> 01818 generic/250 run fstests generic/250 at 2022-05-28 23:48:09
> 01818 EXT4-fs (dm-0): mounted filesystem with ordered data
Not quite sure whose bug this is. Current Linus head running xfstests
against ext4 (probably not ext4's fault?)
01818 generic/250 run fstests generic/250 at 2022-05-28 23:48:09
01818 EXT4-fs (dm-0): mounted filesystem with ordered data mode. Quota mode:
none.
01818 EXT4-fs (dm-0):
14 matches
Mail list logo
