On Tue, Apr 25, 2017 at 05:33:19PM -0700, Adrian Salido wrote:
> it's actually the data portion of the struct under a custom user ioctl
> where (param_kernel->data_size - minimum_data_size) <
> sizeof(param_kernel->data)
> Will update the patch to be clear
Yes - but before updating the patch, we
On Tue, Apr 25, 2017 at 04:31:29PM -0700, Adrian Salido wrote:
> Struct dm_ioctl has some padding/data that is not explicitly cleared
> before copying to user. This can cause kernel stack contents to be
> leaked to user space.
Please be more precise here, explaining which part of the buffer
and
On Fri, Apr 21, 2017 at 6:06 PM, Dan Williams wrote:
> [ adding akpm, sfr, and jens ]
>
> I applied this series and pushed it out for the nvdimm.git branch that
> gets auto pulled into -next. The set is still awaiting acks from
> device-mapper, ext4, xfs, and vfs (for
Hi,
Redefined devices, with a regex in product/vendor, in multipath.conf
appear twice in multipath config.
Place attached multipath.conf in /etc, and run multipath -t.
For NETAPP/LUN it works OK. Only one is displayed.
But "^DGC"/"^(RAID|DISK|VRAID)" appears twice.
Thank you.
devices {
On Tue, Apr 25, 2017 at 04:26:06PM +0200, Xose Vazquez Perez wrote:
> Hi,
>
> These values:
What do you think of these?
> no_path_retry
The default if no_path_retry is set is to use the features line to
determine what to do when there are no paths. we could have it
print something like
Benjamin: thanks for replying. We have found the root cause to be
stale read buffer at backend.
After zeroing out read buffer upon read miss the problem is gone.
-Shawn
On Tue, Apr 25, 2017 at 9:39 AM, Benjamin Marzinski wrote:
> On Wed, Apr 19, 2017 at 02:58:47PM -0700,
On Tue, Apr 25, 2017 at 03:38:38PM +0200, Xose Vazquez Perez wrote:
> On 03/12/2009 07:38 PM, Benjamin Marzinski wrote:
> Old patch.
>
> > Even when the last path of a multipath device is deleted, it can't be
> > removed until all the queued IO is flushed. For devices that have
> >
On 04/25/2017 05:52 PM, Benjamin Marzinski wrote:
On Tue, Apr 25, 2017 at 12:12:25PM +0200, Steffen Maier wrote:
On 04/25/2017 12:39 AM, Benjamin Marzinski wrote:
When users run kpartx, they would naturally assume that when it
completes, the devices have been created. However, kpartx runs in
On Wed, Apr 19, 2017 at 02:58:47PM -0700, Neutron Sharc wrote:
> I'm seeing a strange problem (iscsi LUNs + dm-multipath + lvm) that I
> will walk through an example to explain.
>
> I have an iscsi target machine that exposes many iscsi LUNs. Iscsi
> initiator logs in 4 iscsi LUNs (vol1_[0-3]),
On Tue, Apr 25, 2017 at 12:12:25PM +0200, Steffen Maier wrote:
>
> On 04/25/2017 12:39 AM, Benjamin Marzinski wrote:
> >When users run kpartx, they would naturally assume that when it
> >completes, the devices have been created. However, kpartx runs in async
> >mode by default. This seems like
Hi,
These values:
no_path_retry
dev_loss_tmo
reservation_key
partition_delimite
delay_watch_checks
delay_wait_checks
are missing from the "defaults section" of multipath -t output.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On 12/06/2016 04:22 PM, Benjamin Marzinski wrote:
> On Tue, Dec 06, 2016 at 04:11:42PM +0100, Xose Vazquez Perez wrote:
>> On 10/29/2016 04:55 AM, Benjamin Marzinski wrote:
>>
>>> Multipathd uses retrigger_tries to give udev more chances to to fill in
>>> the uid_attribute, so that the path
On 03/12/2009 07:38 PM, Benjamin Marzinski wrote:
Old patch.
> Even when the last path of a multipath device is deleted, it can't be
> removed until all the queued IO is flushed. For devices that have
> no_path_retry set to queue, this doesn't automatically happen.
>
> This patch
On 04/25/2017 12:39 AM, Benjamin Marzinski wrote:
When users run kpartx, they would naturally assume that when it
completes, the devices have been created. However, kpartx runs in async
mode by default. This seems like it is likely to trip up users. So,
switch the default to sync mode, add a
24.04.2017 07:05, NeilBrown пишет:
> On Fri, Apr 21 2017, Andrei Borzenkov wrote:
>
>> See as example https://bugzilla.opensuse.org/show_bug.cgi?id=983221
>>
>> "non-standard" DM targets do not appear to be autoloaded (the problem
>> was hit with thin-pool, but it seems to apply to other targets
15 matches
Mail list logo