John,
>> So disallowing WRITE SAME unless all component devices have the same LBS
>> is the correct fix.
>
> Alternately, could possibly WRITE_SAME bios be accepted with the
> minimum sector size of the stack rather than the max, e.g. 512 in this
> example rather than 4k? They'd need to have a g
Marginal paths are SHAKY, so they don't count towards the number of
active paths. poll_io_err_stat() shouldn't automatically reinstate a
marginal path if there already is an active path.
Signed-off-by: Benjamin Marzinski
---
libmultipath/io_err_stat.c | 2 +-
1 file changed, 1 insertion(+), 1 de
When a path gets recovered in hit_io_err_recheck_time(), it will
continue running in check_path(), so there is no reason to schedule
another path check as soon as possible (since one is currently
happening).
Also, there isn't much point in restarting the io err stat checking when
the path is down,
The current marginal paths code tries to enqueue paths for io error
checking when multipathd receives a uevent on path failure. This can run
into a couple of problems. First, this uevent could happen before or
after multipathd actually fails the path, so simply checking nr_active
doesn't tell us if
I've been playing around with the marginal path code, and I've run into
a couple of things that could be cleaned up. The one important issue is
that the marginal paths code tries to enqueue the path for IO error
checking when it is down. To enqueue the path, it needs to open the
device, which can
If the path that enqueue_io_err_stat_by_path() is trying to add
is already on the list, just return success. There's no reason
to fail in this case.
Signed-off-by: Benjamin Marzinski
---
libmultipath/io_err_stat.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libmulti
NetApp has tools that rely on devices using WWID names. To avoid
breaking these, NetApp devices should continue to use WWID names, even
if the default config is set to enable user_friendly_names. If users
want to use user_friendly_names on NetApp devices, the must specifically
override the device c
On Mon, Jan 28, 2019 at 11:54 PM Martin K. Petersen
wrote:
> We rounded up LBS when we created the DM device. And therefore the
> bv_len coming down is 4K. But one of the component devices has a LBS of
> 512 and fails this check.
>
> At first glance one could argue we should just nuke the BUG_ON s
On 1/29/2019 4:52 PM, Christoph Hellwig wrote:
On Mon, Jan 28, 2019 at 11:54:08PM -0500, Martin K. Petersen wrote:
That said, now that we have REQ_OP_WRITE_ZEROES (where the LBS is
irrelevant due to the payload being the ZERO_PAGE), it may be worthwhile
to remove REQ_OP_WRITE_SAME. I think dr