On Fri, 2020-07-03 at 12:39 -0400, Mike Snitzer wrote:
>
> Docker couldn't have later opens fail due to a pending removal --
> it'd
> break their app. So if you want it to do what you'd have imagined it
> to
> be; we'll need to introduce a new flag that alters the behavior
> (maybe
> as a module
On Fri, Jul 03 2020 at 11:12am -0400,
Martin Wilck wrote:
> On Thu, 2020-07-02 at 14:41 -0500, Benjamin Marzinski wrote:
> > On Thu, Jul 02, 2020 at 04:45:21PM +, Martin Wilck wrote:
> > >
> > > What's wrong with deferred remove? After all, the user explicitly
> > > asked
> > > for a flush.
On Thu, 2020-07-02 at 14:41 -0500, Benjamin Marzinski wrote:
> On Thu, Jul 02, 2020 at 04:45:21PM +, Martin Wilck wrote:
> >
> > What's wrong with deferred remove? After all, the user explicitly
> > asked
> > for a flush. As long as some other process has the device open, it
> > won't be
On Thu, Jul 02, 2020 at 04:45:21PM +, Martin Wilck wrote:
> On Thu, 2020-07-02 at 10:18 -0500, Benjamin Marzinski wrote:
> > On Thu, Jul 02, 2020 at 12:24:32PM +, Martin Wilck wrote:
> > > On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> > > > On Wed, Jul 01, 2020 at
On Thu, 2020-07-02 at 10:18 -0500, Benjamin Marzinski wrote:
> On Thu, Jul 02, 2020 at 12:24:32PM +, Martin Wilck wrote:
> > On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> > > On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> > > > On Thu, 2020-06-18 at 18:06
On Thu, Jul 02, 2020 at 12:24:32PM +, Martin Wilck wrote:
> On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> > On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> > > On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
> > > > I uploaded the test program,
On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> > On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
> > > I uploaded the test program, aio_test:
> > >
> > > https://github.com/bmarzins/test_programs.git
> >
On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
> >
> > I uploaded the test program, aio_test:
> >
> > https://github.com/bmarzins/test_programs.git
> >
> > You just need to run in on a queueing multipath device with
On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
>
> I uploaded the test program, aio_test:
>
> https://github.com/bmarzins/test_programs.git
>
> You just need to run in on a queueing multipath device with no active
> paths and an open count of 0. It will hang with the device open.
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, 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
>
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 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
>
If a multipath device is removed, and check_path() checks one of its
paths before multipathd processes either the uevent or the dm event from
removing it, multipathd will recreate the removed device. This happens
because check_path() will continute to check the removed device's former
paths until
14 matches
Mail list logo