From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <Martin.Wilck@suse.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH 2/3] libmutipath: don't close fd on dm_lib_release
Date: Wed, 25 Mar 2020 17:00:45 -0500 [thread overview]
Message-ID: <20200325220045.GC17313@octiron.msp.redhat.com> (raw)
In-Reply-To: <20200325205255.GB17313@octiron.msp.redhat.com>
On Wed, Mar 25, 2020 at 03:52:55PM -0500, Benjamin Marzinski wrote:
> On Wed, Mar 25, 2020 at 03:16:50PM +0000, Martin Wilck wrote:
> > On Tue, 2020-03-24 at 16:03 -0500, Benjamin Marzinski wrote:
> >
> > AFAICS, this function has been in libdm since 1.02.111. We support
> > 1.02.89 (if all features enabled, otherwise even older). Perhaps we
> > should make this function call conditional on the libdm verson?
> >
> > But perhaps more importantly, why do we still need to call
> > dm_lib_release()? AFAICS it's only needed for systems that have no udev
> > support for creating device nodes (to call update_devs() via
> > dm_lib_release()), and we don't support that anymore anyway, do we?
> >
> > Since 26c4bb0, we're always setting the
> > DM_UDEV_DISABLE_LIBRARY_FALLBACK flag, and the cookie, too
> > (we aren't setting it for DM_DEVICE_RELOAD, but it isn't needed for
> > that, either, since no device nodes need to be created or removed); so
> > dm_lib_release() should really have no effect.
> >
> > Regards
> > Martin
>
> Good call. I'll redo this patch.
Actually, I've changed my mind. Calling dm_lib_release() lets us release
the memory that device-mapper uses to store all the node ops that it
was saving up. Without calling dm_lib_release(), AFAICS, that memory
keeps growing until the daemon exits.
-Ben
> -Ben
>
> >
> > --
> > Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
> > SUSE Software Solutions Germany GmbH
> > HRB 36809, AG Nürnberg GF: Felix
> > Imendörffer
> >
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2020-03-25 22:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 21:03 [PATCH 1/3] libmultipath: assign variable to make gcc happy Benjamin Marzinski
2020-03-24 21:03 ` [PATCH 2/3] libmutipath: don't close fd on dm_lib_release Benjamin Marzinski
2020-03-25 15:16 ` Martin Wilck
2020-03-25 20:52 ` Benjamin Marzinski
2020-03-25 22:00 ` Benjamin Marzinski [this message]
2020-03-25 22:11 ` Martin Wilck
2020-07-02 11:52 ` Martin Wilck
2020-07-02 20:06 ` Benjamin Marzinski
2020-07-03 14:05 ` Martin Wilck
2020-03-24 21:03 ` [PATCH 3/3] libmultipath: allow force reload with no active paths Benjamin Marzinski
2020-03-25 15:27 ` Martin Wilck
2020-03-25 15:22 ` [PATCH 1/3] libmultipath: assign variable to make gcc happy Martin Wilck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200325220045.GC17313@octiron.msp.redhat.com \
--to=bmarzins@redhat.com \
--cc=Martin.Wilck@suse.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.