On 6/19/20 1:17 AM, Benjamin Marzinski wrote:
On Thu, Jun 18, 2020 at 07:34:38PM +, Martin Wilck wrote:
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
If a multipath device is removed during, or immediately before the
call
to check_path(), multipathd can behave incorrectly. A
On Thu, Jun 18, 2020 at 07:34:38PM +, Martin Wilck wrote:
> On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> > If a multipath device is removed during, or immediately before the
> > call
> > to check_path(), multipathd can behave incorrectly. A missing
> > multpath
> > device will
On Thu, Jun 18, 2020 at 03:27:22PM +, Martin Wilck wrote:
> On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> > Make do_get_info() differentiate between dm failures and missing
> > devices, and update callers to retain their current behavior. Also,
> > rename it and make it externa
On Thu, Jun 18, 2020 at 08:44:10PM +, Martin Wilck wrote:
> On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> > Add the -D option to allow users to skip delegating commands to
> > multipathd.
> >
> > Signed-off-by: Benjamin Marzinski
> > ---
> > libmultipath/config.h | 1 +
> >
On Thu, Jun 18, 2020 at 08:37:20PM +, Martin Wilck wrote:
> On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> > This will flush all multipath devices.
> >
> > Signed-off-by: Benjamin Marzinski
> > ---
> > libmultipath/devmapper.c | 7 +--
> > libmultipath/devmapper.h | 2
On Thu, Jun 18, 2020 at 08:06:53PM +, Martin Wilck wrote:
> On Thu, 2020-06-18 at 13:04 -0500, Benjamin Marzinski wrote:
> > On Thu, Jun 18, 2020 at 09:00:49AM +, Martin Wilck wrote:
> > >
> > > With queue_if_no_paths, there could be outstanding IO even if the
> > > opencount was 0.
> >
>
On Thu, Jun 18, 2020 at 11:44:45AM -0400, Mike Snitzer wrote:
> I do not accept that panicing the system because of verity failure is
> reasonable.
>
> In fact, even rebooting (via DM_VERITY_MODE_RESTART) looks very wrong.
>
> The device should be put in a failed state and left for admin recovery
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> Add the -D option to allow users to skip delegating commands to
> multipathd.
>
> Signed-off-by: Benjamin Marzinski
> ---
> libmultipath/config.h | 1 +
> multipath/main.c | 15 +++
> multipath/multipath.8 | 16
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> Since there can be problems with removing maps outside of multipathd,
> multipath should attempt to delegate this command to multipathd.
> However, multipathd doesn't attempt to suspend the device, in order
> to avoid potential hangs. I
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> The config structure doesn't need a special variable just for
> removes.
> Multipath can just use the cmd variable, like it does for the other
> commands.
>
> Signed-off-by: Benjamin Marzinski
Reviewed-by: Martin Wilck
--
Dr. Mart
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> This will flush all multipath devices.
>
> Signed-off-by: Benjamin Marzinski
> ---
> libmultipath/devmapper.c | 7 +--
> libmultipath/devmapper.h | 2 +-
> multipath/main.c | 2 +-
> multipathd/cli.c | 1 +
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> dm_flush_maps() returned both 0 and 1 on error, depending on which
> part
> of the function it was in, but the caller was always treating 0 as a
> success. Make dm_flush_maps() always return 1 on error and 0 on
> success.
>
> Signed-of
On Thu, 2020-06-18 at 13:04 -0500, Benjamin Marzinski wrote:
> On Thu, Jun 18, 2020 at 09:00:49AM +, Martin Wilck wrote:
> >
> > With queue_if_no_paths, there could be outstanding IO even if the
> > opencount was 0.
>
> This is what I don't accept at face value. I wrote a little test
> progra
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> If a multipath device is removed during, or immediately before the
> call
> to check_path(), multipathd can behave incorrectly. A missing
> multpath
> device will cause update_multipath_strings() to fail, setting
> pp->dmstate to PSTATE
On Thu, Jun 18, 2020 at 09:00:49AM +, Martin Wilck wrote:
> On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> >
> > One source of complexity in these patches is that multipath suspends
> > the
> > device with flushing before removing it, while multipathd
> > doesn't. It
> > does
On Thu, Jun 18 2020 at 12:50pm -0400,
Sami Tolvanen wrote:
> On Thu, Jun 18, 2020 at 11:44:45AM -0400, Mike Snitzer wrote:
> > I do not accept that panicing the system because of verity failure is
> > reasonable.
> >
> > In fact, even rebooting (via DM_VERITY_MODE_RESTART) looks very wrong.
> >
On Thu, Jun 18 2020 at 2:56am -0400,
JeongHyeon Lee wrote:
> Hello, Dear devcice-mapper maintainers.
>
> I'm JeongHyeon Lee, work in Samsung. I'm chage of DM-Verity feature with
> Mr. sunwook eom.
> I have a patch or suggestion about DM-Verity error handling.
>
> Our device (smart phone) need
On Thu, Jun 18 2020 at 5:06am -0400,
yangerkun wrote:
>
> This patchset will list badblocks while we do 'dmsetup status'.
>
> Image that we have mark block 1 and 2 as bad block, run following
> command will list all bad blocks:
>
> $ sudo dmsetup status dust1
> 0 33552384 dust 252:17
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> Make do_get_info() differentiate between dm failures and missing
> devices, and update callers to retain their current behavior. Also,
> rename it and make it external. These changes will be used by future
> commits.
>
> Signed-off-by:
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
>
> One source of complexity in these patches is that multipath suspends
> the
> device with flushing before removing it, while multipathd
> doesn't. It
> does seem possible that the suspend could hang for a while, so I can
> understand
Hello, Dear devcice-mapper maintainers.
I'm JeongHyeon Lee, work in Samsung. I'm chage of DM-Verity feature with
Mr. sunwook eom.
I have a patch or suggestion about DM-Verity error handling.
Our device (smart phone) need DM-Verity feature. So I hope there is new
mode DM-Verity error handling.
T
21 matches
Mail list logo
