On Tue, Dec 22, 2020 at 09:06:04PM +, Alasdair G Kergon wrote:
> I have not read the background about whatever the new problem is - I'm
> jumping in cold seeing this message - but from the very beginning of
> device-mapper we have strongly recommended that userspace supplies the
> block device
On Tue, Dec 22, 2020 at 06:24:09PM +0100, Hannes Reinecke wrote:
> Ok. The problem from my perspective is that device-mapper needs to
> a) ensure that the arbitrary string passed in with the table definition
> refers to a valid block device
> and
> b) the block device can be opened with O_EXCL,
On Tue, Dec 22, 2020 at 06:24:09PM +0100, Hannes Reinecke wrote:
> However, lookup_bdev() now always recurses into the filesystem, causing
> multipath to stall in an all-paths-down scenario.
I have not read the background about whatever the new problem is - I'm
jumping in cold seeing this
On 12/22/20 3:53 PM, Mike Snitzer wrote:
[added linux-block and dm-devel, if someone replies to this email to
continue "proper discussion" _please_ at least drop sfr and linux-next
from Cc]
On Tue, Dec 22 2020 at 8:15am -0500,
Christoph Hellwig wrote:
Mike, Hannes,
I think this patch is
[added linux-block and dm-devel, if someone replies to this email to
continue "proper discussion" _please_ at least drop sfr and linux-next
from Cc]
On Tue, Dec 22 2020 at 8:15am -0500,
Christoph Hellwig wrote:
> Mike, Hannes,
>
> I think this patch is rather harmful. Why does device mapper
