On Wed, 2024-01-31 at 14:45 -0800, Brian Bunker wrote:
> If 'detect_prio' is set to 'yes', the 'sysfs' prioritizer will be
> used
> instead of the 'alua' prioritizer. The 'sysfs' prioritizer can leave
> paths in the Active/Non-optimized ALUA state after a successful
> upgrade of a PURE FlashArray.
On Tue, Jan 30, 2024 at 03:26:34PM -0500, Mike Snitzer wrote:
> From: Hongyu Jin
>
> Commit 82b74cac2849 ("blk-ioprio: Convert from rqos policy to direct
> call") pushed setting bio I/O priority down into blk_mq_submit_bio()
> -- which is too low within block core's submit_bio() because it
>
On Wed, Jan 31 2024 at 7:04P -0500,
Tejun Heo wrote:
> Hello, Linus.
>
> On Wed, Jan 31, 2024 at 03:19:01PM -0800, Linus Torvalds wrote:
> > On Wed, 31 Jan 2024 at 13:32, Tejun Heo wrote:
> > >
> > > I don't know, so just did the dumb thing. If the caller always guarantees
> > > that the work
On Wed, Jan 31 2024 at 6:19P -0500,
Linus Torvalds wrote:
> On Wed, 31 Jan 2024 at 13:32, Tejun Heo wrote:
> >
> > I don't know, so just did the dumb thing. If the caller always guarantees
> > that the work items are never queued at the same time, reusing is fine.
>
> So the reason I thought
Hello, Linus.
On Wed, Jan 31, 2024 at 03:19:01PM -0800, Linus Torvalds wrote:
> On Wed, 31 Jan 2024 at 13:32, Tejun Heo wrote:
> >
> > I don't know, so just did the dumb thing. If the caller always guarantees
> > that the work items are never queued at the same time, reusing is fine.
>
> So the
On Wed, 31 Jan 2024 at 13:32, Tejun Heo wrote:
>
> I don't know, so just did the dumb thing. If the caller always guarantees
> that the work items are never queued at the same time, reusing is fine.
So the reason I thought it would be a good cleanup to introduce that
"atomic" workqueue thing
If 'detect_prio' is set to 'yes', the 'sysfs' prioritizer will be used
instead of the 'alua' prioritizer. The 'sysfs' prioritizer can leave
paths in the Active/Non-optimized ALUA state after a successful
upgrade of a PURE FlashArray. Explicitly use the 'alua' prioritizer
instead for PURE
> On Jan 31, 2024, at 12:12 PM, Martin Wilck wrote:
>
> Hi Brian,
>
> On Wed, 2024-01-31 at 09:45 -0800, Brian Bunker wrote:
>>
>>
>>> On Jan 31, 2024, at 2:19 AM, Martin Wilck wrote:
>>>
>>> Hi Brian,
>>>
>>> On Tue, 2024-01-30 at 10:43 -0800, Brian Bunker wrote:
>
> A full
Mathieu Desnoyers wrote:
> On 2024-01-31 16:02, Dan Williams wrote:
> > Mathieu Desnoyers wrote:
> >> Replace the following fs/Kconfig:FS_DAX dependency:
> >>
> >>depends on !(ARM || MIPS || SPARC)
> >>
> >> By a runtime check within alloc_dax().
> >>
> >> This is done in preparation for its
On Wed, 31 Jan 2024, Tejun Heo wrote:
> Hello,
>
> On Wed, Jan 31, 2024 at 10:19:07PM +0100, Mikulas Patocka wrote:
> > > @@ -83,7 +83,7 @@ struct dm_verity_io {
> > > struct bvec_iter iter;
> > >
> > > struct work_struct work;
> > > - struct tasklet_struct tasklet;
> > > + struct
On 2024-01-31 16:02, Dan Williams wrote:
Mathieu Desnoyers wrote:
Replace the following fs/Kconfig:FS_DAX dependency:
depends on !(ARM || MIPS || SPARC)
By a runtime check within alloc_dax().
This is done in preparation for its use by each filesystem supporting
the "dax" mount option to
Hello,
On Wed, Jan 31, 2024 at 10:19:07PM +0100, Mikulas Patocka wrote:
> > @@ -83,7 +83,7 @@ struct dm_verity_io {
> > struct bvec_iter iter;
> >
> > struct work_struct work;
> > - struct tasklet_struct tasklet;
> > + struct work_struct bh_work;
> >
> > /*
> > * Three
This seems OK.
Reviewed-by: Mikulas Patocka
On Mon, 29 Jan 2024, Tejun Heo wrote:
> The only generic interface to execute asynchronously in the BH context is
> tasklet; however, it's marked deprecated and has some design flaws. To
> replace tasklets, BH workqueue support was recently added.
On Mon, 29 Jan 2024, Tejun Heo wrote:
> The only generic interface to execute asynchronously in the BH context is
> tasklet; however, it's marked deprecated and has some design flaws. To
> replace tasklets, BH workqueue support was recently added. A BH workqueue
> behaves similarly to regular
Mathieu Desnoyers wrote:
> Replace the following fs/Kconfig:FS_DAX dependency:
>
> depends on !(ARM || MIPS || SPARC)
>
> By a runtime check within alloc_dax().
>
> This is done in preparation for its use by each filesystem supporting
> the "dax" mount option to validate whether DAX is indeed
Tasklets have an inherent problem with memory corruption. The function
tasklet_action_common calls tasklet_trylock, then it calls the tasklet
callback and then it calls tasklet_unlock. If the tasklet callback frees
the structure that contains the tasklet or if it calls some code that may
free it,
Mathieu Desnoyers wrote:
> On 2024-01-31 12:17, Christoph Hellwig wrote:
> > So this is the third iteration and you still keep only sending patch
> > 3 to the list. How is anyone supposed to review it if you don't send
> > them all the pieces?
>
> My bad. I was aiming for not spamming mailing
On Wed, Jan 31, 2024 at 09:12:23PM +0100, Martin Wilck wrote:
> Hi Brian,
> > This is what we are doing now in our recommended configuration. I
> > will
> > probably add a patch for our hw table entry soon. It is a bit strange
> > to
> > me still that detect_prio would mean replace the one that I
Hi Brian,
On Wed, 2024-01-31 at 09:45 -0800, Brian Bunker wrote:
>
>
> > On Jan 31, 2024, at 2:19 AM, Martin Wilck wrote:
> >
> > Hi Brian,
> >
> > On Tue, 2024-01-30 at 10:43 -0800, Brian Bunker wrote:
> > > >
> > > > A full rescan shouldn't be necessary. All that's needed is that
> > > >
On 2024-01-31 12:17, Christoph Hellwig wrote:
So this is the third iteration and you still keep only sending patch
3 to the list. How is anyone supposed to review it if you don't send
them all the pieces?
My bad. I was aiming for not spamming mailing lists on unrelated patches. I did
not CC
> On Jan 31, 2024, at 2:19 AM, Martin Wilck wrote:
>
> Hi Brian,
>
> On Tue, 2024-01-30 at 10:43 -0800, Brian Bunker wrote:
>>>
>>> A full rescan shouldn't be necessary. All that's needed is that the
>>> kernel issue another RTPG. AFAICS that should happen as soon as the
>>> target responds
So this is the third iteration and you still keep only sending patch
3 to the list. How is anyone supposed to review it if you don't send
them all the pieces?
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
prevents DAX from building on architectures with virtually aliased
dcache with:
depends on !(ARM || MIPS || SPARC)
This check is too broad (e.g. recent ARMv7 don't have virtually aliased
dcaches), and also
Introduce a generic way to query whether the data cache is virtually
aliased on all architectures. Its purpose is to ensure that subsystems
which are incompatible with virtually aliased data caches (e.g. FS_DAX)
can reliably query this.
For data cache aliasing, there are three scenarios
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of dm alloc_dev()
to treat alloc_dax() failure as non-fatal.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Suggested-by: Dan Williams
This commit introduced in v5.13 prevents building FS_DAX on 32-bit ARM,
even on ARMv7 which does not have virtually aliased data caches:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
It used to work fine before: I have customers using DAX over pmem on
ARMv7,
Replace the following fs/Kconfig:FS_DAX dependency:
depends on !(ARM || MIPS || SPARC)
By a runtime check within alloc_dax().
This is done in preparation for its use by each filesystem supporting
the "dax" mount option to validate whether DAX is indeed supported.
This is done in preparation
The Infinibox hwtable entry had fast_io_fail and dev_loss both set to 15,
which has the effect that fast_io_fail is switched off (dev_loss timeout
must be higher than fast_io_fail timeout).
Remove the dev_loss value, which will cause the default of 600 to be used.
Experience shows that
On Tue, 2024-01-30 at 13:45 -0500, Benjamin Marzinski wrote:
> two small fixes.
>
> Benjamin Marzinski (2):
> libmultipath: fix displaying auto_resize config setting
> multipath-tools tests: add void parameter to functions
>
> libmultipath/dict.c | 2 --
> tests/alias.c | 4 ++--
> 2
Hi Brian,
On Tue, 2024-01-30 at 10:43 -0800, Brian Bunker wrote:
> >
> > A full rescan shouldn't be necessary. All that's needed is that the
> > kernel issue another RTPG. AFAICS that should happen as soon as the
> > target responds to any command with a sense key of UNIT ATTENTION
> > with
> >
30 matches
Mail list logo
