On Sun, Apr 07, 2024 at 12:47:10AM +0800, Kuan-Wei Chiu wrote:
> This patch series focuses on several adjustments related to heap
> implementation. Firstly, a type-safe interface has been added to the
> min_heap, along with the introduction of several new functions to
> enhance its functionality.
It was reported that dm-crypt performs badly when the system is loaded[1].
So I'm adding an option "high_priority" that sets the workqueues and the
write_thread to nice level -20. This used to be default in the past, but
it caused audio skipping, so it had to be reverted - see the commit
On Thu, Apr 04, 2024 at 07:38:11PM +0200, Martin Wilck wrote:
> We don't need to restore DM_NOSCAN from the db anymore, so we can rename
> it to .DM_NOSCAN, making it a temporary property.
>
> Signed-off-by: Martin Wilck
> ---
> multipath/11-dm-mpath.rules.in | 9 ++---
> 1 file changed, 6
On Thu, Apr 04, 2024 at 07:38:10PM +0200, Martin Wilck wrote:
> With the late changes to the device mapper rules, DM_SUSPENDED
> is not exported any more. Use .DM_SUSPENDED instead.
>
> Note that although 11-dm-mpath.rules is not a part of lvm2, it
> can be considered as part of the device-mapper
On Thu, Apr 04, 2024 at 07:38:09PM +0200, Martin Wilck wrote:
> With the late changes to 13-dm-disk.rules, we don't need to import any
> blkid-generated properties from the udev database, because they will
> be imported later.
>
> Except for ID_FS_TYPE, this actually holds since lvm2 commit
On Thu, Apr 04, 2024 at 07:38:08PM +0200, Martin Wilck wrote:
> With late late patches for 10-dm.rules, DM_UDEV_DISABLE_OTHER_RULES_FLAG is
> never restored from the udev db. Thus we don't need to clear it here
> any more for coldplug events. Also, we must use .DM_SUSPENDED instead of
>
On Thu, Apr 04, 2024 at 07:38:07PM +0200, Martin Wilck wrote:
> With the late patches for 10-dm.rules, DM_UDEV_DISABLE_OTHER_RULES_FLAG isn't
> restored from the udev database any more, so we don't need to restore
> the flag to its original state before it is saved to the db.
>
> Signed-off-by:
On Thu, Apr 04, 2024 at 07:38:05PM +0200, Martin Wilck wrote:
> DM_NOSCAN is our "output" flag for 13-dm-disk.rules, and it should
> be treated the same way as DM_UDEV_DISABLE_OTHER_RULES_FLAG, which
> isn't imported from the udev database. The state that we need to
> remember is
On Thu, Apr 04, 2024 at 07:38:04PM +0200, Martin Wilck wrote:
> Add a comment to explain why we must set MPATH_DEVICE_READY=0 when
> we see a device becoming ready (number of active paths 0 -> 1) while
> the device is suspended.
>
> Signed-off-by: Martin Wilck
Reviewed-by: Benjamin Marzinski
>
On 08.04.24 03:42, Damien Le Moal wrote:
> @@ -608,6 +633,7 @@ int blk_revalidate_disk_zones(struct gendisk *disk,
>
> kfree(args.seq_zones_wlock);
> kfree(args.conv_zones_bitmap);
> +
> return ret;
> }
> EXPORT_SYMBOL_GPL(blk_revalidate_disk_zones);
Unrelated whitespace
Reviewed-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
On 2024-04-08 09:36, Ming Lei wrote:
It isn't now we put the limit, and this way has been done for stacking
device
since beginning, it is actually added by commit d690cb8ae14b in
v6.9-rc1.
If max segment size isn't aligned with virt_boundary_mask,
bio_split_rw()
will split the bio with max
On Mon, Apr 08, 2024 at 10:47:39AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 08, 2024 at 03:36:50PM +0800, Ming Lei wrote:
> > It isn't now we put the limit, and this way has been done for stacking
> > device
> > since beginning, it is actually added by commit d690cb8ae14b in v6.9-rc1.
> >
>
On Mon, Apr 08, 2024 at 03:36:50PM +0800, Ming Lei wrote:
> It isn't now we put the limit, and this way has been done for stacking device
> since beginning, it is actually added by commit d690cb8ae14b in v6.9-rc1.
>
> If max segment size isn't aligned with virt_boundary_mask, bio_split_rw()
>
On Mon, Apr 08, 2024 at 07:55:42AM +0200, Christoph Hellwig wrote:
> On Sun, Apr 07, 2024 at 09:19:31PM +0800, Ming Lei wrote:
> > When one stacking device is over one device with virt_boundary_mask and
> > another one with max segment size, the stacking device have both limits
> > set. This way
FYI, this still looks good to me with the minor changes from the
last two iterations.
20 matches
Mail list logo
