Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1495014 > unrolled thread

[PATCH 0/9] Generate uevents for all DM events

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/9] Generate uevents for all DM events Andy Grover <agrover@redhat.com> - 2016-10-03 21:30 +0200
    [PATCH 4/9] dm: Update dm-uevent.txt Andy Grover <agrover@redhat.com> - 2016-10-03 21:30 +0200
    [PATCH 7/9] dm: Implement dm_uevent_add() Andy Grover <agrover@redhat.com> - 2016-10-03 21:30 +0200
    [PATCH 9/9] dm: Generate uevents for other targets Andy Grover <agrover@redhat.com> - 2016-10-03 21:30 +0200
    [PATCH 3/9] dm: Inline dm_build_path_uevent into dm_path_uevent Andy Grover <agrover@redhat.com> - 2016-10-03 21:30 +0200
    Re: [PATCH 0/9] Generate uevents for all DM events Greg KH <gregkh@linuxfoundation.org> - 2016-10-04 09:50 +0200
      Re: [PATCH 0/9] Generate uevents for all DM events Andy Grover <agrover@redhat.com> - 2016-10-05 01:40 +0200
        Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events Alasdair G Kergon <agk@redhat.com> - 2016-10-05 02:50 +0200
          Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events Hannes Reinecke <hare@suse.de> - 2016-10-05 08:30 +0200
          Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events Greg KH <gregkh@linuxfoundation.org> - 2016-10-05 09:00 +0200
            Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events Andy Grover <agrover@redhat.com> - 2016-10-05 19:10 +0200
              Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events Alasdair G Kergon <agk@redhat.com> - 2016-10-05 19:50 +0200
                Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events Andy Grover <agrover@redhat.com> - 2016-10-06 00:40 +0200

#1495014 — [PATCH 0/9] Generate uevents for all DM events

Hi Mike and GregKH,

I want a way to get devicemapper events without using the DM ioctl,
because that requires creating a thread to sleep in the ioctl for each
dm device I want events from.

It would seem like using uevents and KOBJ_CHANGE would be a good way
to do this, but Mike said that the uevent maintainers (Greg that's
you?) did not think this was a good idea?

If so, I was hoping you could talk a little more about why -- grep
shows KOBJ_CHANGE used all over, but its usage is not documented in
kobject.txt. In any case I can update kobject.txt with some more
guidelines.

The following patchset may be appliable if you're actually ok with
using KOBJ_CHANGE for dm events, or if not, then I'll look to rework
it to use a dm-specific genetlink approach.

Thanks -- Regards -- Andy

Andy Grover (9):
  dm: Do not export dm_send_uevents
  dm: Move multipath-specific stuff out of dm-uevent.c
  dm: Inline dm_build_path_uevent into dm_path_uevent
  dm: Update dm-uevent.txt
  dm: Rename dm_build_uevent to dm_uevent_build
  dm: Rename dm_event_add to dm_event_queue
  dm: Implement dm_uevent_add()
  dm: Generate uevents for thin targets
  dm: Generate uevents for other targets

 Documentation/device-mapper/dm-uevent.txt |  54 ++++++++++++++--
 drivers/md/dm-cache-target.c              |   5 +-
 drivers/md/dm-log-userspace-base.c        |   8 ++-
 drivers/md/dm-log.c                       |   1 +
 drivers/md/dm-mpath.c                     |  56 ++++++++++++++++
 drivers/md/dm-raid1.c                     |   1 +
 drivers/md/dm-snap.c                      |   1 +
 drivers/md/dm-thin.c                      |   3 +
 drivers/md/dm-uevent.c                    | 102 ++++++++++--------------------
 drivers/md/dm-uevent.h                    |  30 +++++++--
 drivers/md/dm.c                           |   3 +-
 include/linux/device-mapper.h             |   3 +-
 12 files changed, 180 insertions(+), 87 deletions(-)

-- 
2.7.4

[toc] | [next] | [standalone]

#1495015 — [PATCH 4/9] dm: Update dm-uevent.txt

Document the current dm uevent API, as modified by this patchset.

Signed-off-by: Andy Grover <agrover@redhat.com>
---
 Documentation/device-mapper/dm-uevent.txt | 49 ++++++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 7 deletions(-)

diff --git a/Documentation/device-mapper/dm-uevent.txt b/Documentation/device-mapper/dm-uevent.txt
index 07edbd85..0a5d909 100644
--- a/Documentation/device-mapper/dm-uevent.txt
+++ b/Documentation/device-mapper/dm-uevent.txt
@@ -1,18 +1,53 @@
 The device-mapper uevent code adds the capability to device-mapper to create
 and send kobject uevents (uevents).  Previously device-mapper events were only
-available through the ioctl interface.  The advantage of the uevents interface
-is the event contains environment attributes providing increased context for
+available through the ioctl interface.  The advantages of the uevents interface
+are the event contains environment attributes providing increased context for
 the event avoiding the need to query the state of the device-mapper device after
-the event is received.
+the event is received, and uevents are poll()-able in userspace, whereas the
+ioctl event interface is not.
 
-There are two functions currently for device-mapper events.  The first function
-listed creates the event and the second function sends the event(s).
+There are five functions DM targets should use.
 
-void dm_path_uevent(enum dm_uevent_type event_type, struct dm_target *ti,
-                    const char *path, unsigned nr_valid_paths)
+struct dm_uevent *dm_build_uevent(struct mapped_device *md,
+					 struct dm_target *ti,
+					 enum kobject_action action,
+					 const char *dm_action)
+
+Construct a dm uevent with default DM variables attached(DM_TARGET,
+DM_ACTION, DM_SEQNUM).
+
+int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...)
+
+Optionally add event-specific data to the generated uevent. e.g. dm-mpath's
+PATH_FAILED and PATH_REINSTATED uevents add path and number-of-remaining-paths
+vars.
+
+void dm_uevent_add(struct mapped_device *md, struct list_head *elist)
+
+Hand off the uevent to the device's list of pending events.
+
+void dm_uevent_free(struct dm_uevent *event)
+
+Something went wrong, free the uevent instead of queueing it.
+
+void dm_table_event(struct dm_table *t)
+
+Triggers sending of queued uevents as well as waking up processes waiting on
+the ioctl.
+
+
+The device-mapper uevent code also supplies three functions for device-mapper core
+to call:
+
+int dm_uevent_init(void)
+void dm_uevent_exit(void)
+
+Setup and teardown.
 
 void dm_send_uevents(struct list_head *events, struct kobject *kobj)
 
+Actually send the uevents (called indirectly from dm_table_event, above).
+
 
 The variables added to the uevent environment are:
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1495016 — [PATCH 7/9] dm: Implement dm_uevent_add()

This helper function builds and enqueues the uevent. Targets can use this
when they do not need to customize the uevent beyond its name.

Signed-off-by: Andy Grover <agrover@redhat.com>
---
 Documentation/device-mapper/dm-uevent.txt |  5 +++++
 drivers/md/dm-uevent.c                    | 26 ++++++++++++++++++++++++++
 include/linux/device-mapper.h             |  1 +
 3 files changed, 32 insertions(+)

diff --git a/Documentation/device-mapper/dm-uevent.txt b/Documentation/device-mapper/dm-uevent.txt
index 4fcb71d..097e7f4 100644
--- a/Documentation/device-mapper/dm-uevent.txt
+++ b/Documentation/device-mapper/dm-uevent.txt
@@ -30,6 +30,11 @@ void dm_uevent_free(struct dm_uevent *event)
 
 Something went wrong, free the uevent instead of queueing it.
 
+void dm_uevent_add(struct dm_target *ti, enum kobject_action action, char *name)
+
+Helper function that builds and queues a uevent if no additional
+variables need to be added.
+
 void dm_table_event(struct dm_table *t)
 
 Triggers sending of queued uevents as well as waking up processes waiting on
diff --git a/drivers/md/dm-uevent.c b/drivers/md/dm-uevent.c
index 6a72de7..d139135 100644
--- a/drivers/md/dm-uevent.c
+++ b/drivers/md/dm-uevent.c
@@ -95,6 +95,32 @@ err_nomem:
 EXPORT_SYMBOL_GPL(dm_uevent_build);
 
 /**
+ * dm_uevent_add - Create and queue a basic uevent
+ *
+ * @ti:		The target to add a uevent for
+ * @action:	The kobject action
+ * @name:	The name of the uevent to add and queue
+ *
+ * If targets wish to create and queue a uevent but don't need to add
+ * extra vars, they can do so more easily by calling this.
+ * This is usually followed by a call to dm_table_event().
+ */
+void dm_uevent_add(struct dm_target *ti, enum kobject_action action, char *name)
+{
+	struct mapped_device *md = dm_table_get_md(ti->table);
+	struct dm_uevent *event;
+
+	event = dm_uevent_build(md, ti, action, name);
+	if (IS_ERR(event)) {
+		DMERR("%s: dm_uevent_build() failed", __func__);
+		return;
+	}
+
+	dm_uevent_queue(md, &event->elist);
+}
+EXPORT_SYMBOL_GPL(dm_uevent_add);
+
+/**
  * dm_send_uevents - send uevents for given list
  *
  * @events:	list of events to send
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 024207c..c102e29 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -420,6 +420,7 @@ uint32_t dm_get_event_nr(struct mapped_device *md);
 int dm_wait_event(struct mapped_device *md, int event_nr);
 uint32_t dm_next_uevent_seq(struct mapped_device *md);
 void dm_uevent_queue(struct mapped_device *md, struct list_head *elist);
+void dm_uevent_add(struct dm_target *ti, enum kobject_action action, char *name);
 
 /*
  * Info functions.
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1495017 — [PATCH 9/9] dm: Generate uevents for other targets

Generate uevents for other targets: cache, log, raid1, and snap.

Signed-off-by: Andy Grover <agrover@redhat.com>
---
 drivers/md/dm-cache-target.c       | 5 ++++-
 drivers/md/dm-log-userspace-base.c | 8 ++++++--
 drivers/md/dm-log.c                | 1 +
 drivers/md/dm-raid1.c              | 1 +
 drivers/md/dm-snap.c               | 1 +
 5 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index 59b2c50..29f0bc9 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -586,8 +586,10 @@ static void clear_dirty(struct cache *cache, dm_oblock_t oblock, dm_cblock_t cbl
 {
 	if (test_and_clear_bit(from_cblock(cblock), cache->dirty_bitset)) {
 		policy_clear_dirty(cache->policy, oblock);
-		if (atomic_dec_return(&cache->nr_dirty) == 0)
+		if (atomic_dec_return(&cache->nr_dirty) == 0) {
+			dm_uevent_add(cache->ti, KOBJ_CHANGE, "CACHE_CLEAN");
 			dm_table_event(cache->ti->table);
+		}
 	}
 }
 
@@ -978,6 +980,7 @@ static void notify_mode_switch(struct cache *cache, enum cache_metadata_mode mod
 		"fail"
 	};
 
+	dm_uevent_add(cache->ti, KOBJ_CHANGE, "CACHE_MODE_SWITCH");
 	dm_table_event(cache->ti->table);
 	DMINFO("%s: switching cache to %s mode",
 	       cache_device_name(cache), descs[(int)mode]);
diff --git a/drivers/md/dm-log-userspace-base.c b/drivers/md/dm-log-userspace-base.c
index 53b7b06d..cb0b6cb 100644
--- a/drivers/md/dm-log-userspace-base.c
+++ b/drivers/md/dm-log-userspace-base.c
@@ -162,8 +162,10 @@ static void do_flush(struct work_struct *work)
 
 	r = userspace_do_request(lc, lc->uuid, DM_ULOG_FLUSH, NULL, 0, NULL, NULL);
 
-	if (r)
+	if (r) {
+		dm_uevent_add(lc->ti->table, KOBJ_CHANGE, "LOG_FLUSHED");
 		dm_table_event(lc->ti->table);
+	}
 }
 
 /*
@@ -634,8 +636,10 @@ out:
 		mempool_free(fe, flush_entry_pool);
 	}
 
-	if (r)
+	if (r) {
+		dm_uevent_add(lc->ti->table, KOBJ_CHANGE, "LOG_FLUSHED");
 		dm_table_event(lc->ti->table);
+	}
 
 	return r;
 }
diff --git a/drivers/md/dm-log.c b/drivers/md/dm-log.c
index 07fc1ad..8d144d2 100644
--- a/drivers/md/dm-log.c
+++ b/drivers/md/dm-log.c
@@ -579,6 +579,7 @@ static void fail_log_device(struct log_c *lc)
 		return;
 
 	lc->log_dev_failed = 1;
+	dm_uevent_add(lc->ti, KOBJ_CHANGE, "LOG_FAILED");
 	dm_table_event(lc->ti->table);
 }
 
diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index bdf1606..daffbab 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -410,6 +410,7 @@ static void do_recovery(struct mirror_set *ms)
 	if (!ms->in_sync &&
 	    (log->type->get_sync_count(log) == ms->nr_regions)) {
 		/* the sync is complete */
+		dm_uevent_add(ms->ti, KOBJ_CHANGE, "TABLE_SYNCED");
 		dm_table_event(ms->ti->table);
 		ms->in_sync = 1;
 		reset_ms_flags(ms);
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index c65feea..b47e28f6 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1443,6 +1443,7 @@ static void __invalidate_snapshot(struct dm_snapshot *s, int err)
 
 	s->valid = 0;
 
+	dm_uevent_add(s->ti, KOBJ_CHANGE, "SNAPSHOT_INVALIDATED");
 	dm_table_event(s->ti->table);
 }
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1495018 — [PATCH 3/9] dm: Inline dm_build_path_uevent into dm_path_uevent

Since it's no longer an API boundary we can consolidate these two
functions.

Signed-off-by: Andy Grover <agrover@redhat.com>
---
 drivers/md/dm-mpath.c | 59 +++++++++++++++++++--------------------------------
 1 file changed, 22 insertions(+), 37 deletions(-)

diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index c563b6d..75fe28a 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1241,38 +1241,6 @@ static void multipath_dtr(struct dm_target *ti)
 	free_multipath(m);
 }
 
-static struct dm_uevent *dm_build_path_uevent(struct mapped_device *md,
-					      struct dm_target *ti,
-					      enum kobject_action action,
-					      const char *dm_action,
-					      const char *path,
-					      unsigned nr_valid_paths)
-{
-	struct dm_uevent *event;
-
-	event = dm_build_uevent(md, ti, action, dm_action);
-	if (IS_ERR(event))
-		return event;
-
-	if (add_uevent_var(&event->ku_env, "DM_PATH=%s", path)) {
-		DMERR("%s: add_uevent_var() for DM_PATH failed", __func__);
-		goto err_add;
-	}
-
-	if (add_uevent_var(&event->ku_env, "DM_NR_VALID_PATHS=%d",
-			   nr_valid_paths)) {
-		DMERR("%s: add_uevent_var() for DM_NR_VALID_PATHS failed",
-		      __func__);
-		goto err_add;
-	}
-
-	return event;
-
-err_add:
-	dm_uevent_free(event);
-	return ERR_PTR(-ENOMEM);
-}
-
 /**
  * dm_path_uevent - called to create a new path event and queue it
  *
@@ -1293,14 +1261,31 @@ static void dm_path_uevent(enum dm_uevent_type event_type, struct dm_target *ti,
 		return;
 	}
 
-	event = dm_build_path_uevent(md, ti,
-				     _dm_mpath_uevent_type_names[event_type].action,
-				     _dm_mpath_uevent_type_names[event_type].name,
-				     path, nr_valid_paths);
-	if (IS_ERR(event))
+	event = dm_build_uevent(md,
+				ti,
+				_dm_mpath_uevent_type_names[event_type].action,
+				_dm_mpath_uevent_type_names[event_type].name);
+	if (IS_ERR(event)) {
+		DMERR("%s: dm_build_uevent() failed", __func__);
 		return;
+	}
+
+	if (add_uevent_var(&event->ku_env, "DM_PATH=%s", path)) {
+		DMERR("%s: add_uevent_var() for DM_PATH failed", __func__);
+		goto err;
+	}
+
+	if (add_uevent_var(&event->ku_env, "DM_NR_VALID_PATHS=%d",
+			   nr_valid_paths)) {
+		DMERR("%s: add_uevent_var() for DM_NR_VALID_PATHS failed",
+		      __func__);
+		goto err;
+	}
 
 	dm_uevent_add(md, &event->elist);
+	return;
+err:
+	dm_uevent_free(event);
 }
 
 /*
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1495244

On Mon, Oct 03, 2016 at 12:22:51PM -0700, Andy Grover wrote:
> Hi Mike and GregKH,
> 
> I want a way to get devicemapper events without using the DM ioctl,
> because that requires creating a thread to sleep in the ioctl for each
> dm device I want events from.
> 
> It would seem like using uevents and KOBJ_CHANGE would be a good way
> to do this, but Mike said that the uevent maintainers (Greg that's
> you?) did not think this was a good idea?

KBOJ_CHANGE is a tricky one.  It has been used for a variety of
different things, but usually it is used to show that a major change has
happened with a device like a docking station plug in or out.

How often do DM events happen?  What is triggering them?  How do you
want to send them to userspace?  Through a sysfs file?  Why not just use
your own netlink connection?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1495628

On 10/04/2016 12:20 AM, Greg KH wrote:
> On Mon, Oct 03, 2016 at 12:22:51PM -0700, Andy Grover wrote:
>> Hi Mike and GregKH,
>>
>> I want a way to get devicemapper events without using the DM ioctl,
>> because that requires creating a thread to sleep in the ioctl for each
>> dm device I want events from.
>>
>> It would seem like using uevents and KOBJ_CHANGE would be a good way
>> to do this, but Mike said that the uevent maintainers (Greg that's
>> you?) did not think this was a good idea?
>
> KBOJ_CHANGE is a tricky one.  It has been used for a variety of
> different things, but usually it is used to show that a major change has
> happened with a device like a docking station plug in or out.
>
> How often do DM events happen?  What is triggering them?  How do you
> want to send them to userspace?  Through a sysfs file?  Why not just use
> your own netlink connection?

devicemapper is using uevents for:

a. dm-verity detected corruption
b. dm-multipath: path failed or reinstated
c. dm device renamed
d. there's also some use in md and bcache.

devicemapper uses DM_EVENT ioctl (yuck) for:

1. dm-thin pool data/metadata filling up (hit a threshold)
2. dm-cache is now clean
3. dm-log flushed or log failed
4. dm-raid error detected or sync complete

Instead of using uevent for everything, we could go to a separate 
genetlink for 1-4 instead of making them use uevent like a-d, but we'd 
end up with two different userspace notification techniques. At least to 
me, there doesn't seem to be much technical differentiation between the 
two lists.

(Would we want to then at some point transition any of a-d off of uevent 
and onto genetlink for consistency's sake?)

Thanks -- Regards -- Andy

[toc] | [prev] | [next] | [standalone]

#1495650 — Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
> devicemapper is using uevents for:
> a. dm-verity detected corruption
> b. dm-multipath: path failed or reinstated
> c. dm device renamed
> d. there's also some use in md and bcache.
>
> devicemapper uses DM_EVENT ioctl (yuck) for:
> 1. dm-thin pool data/metadata filling up (hit a threshold)
> 2. dm-cache is now clean
> 3. dm-log flushed or log failed
> 4. dm-raid error detected or sync complete

> there doesn't seem to be much technical differentiation between the  
> two lists.

The distinction in dm is that events in the first category may affect
the availability of the device: they represent major (and hopefully
rare) changes.

Events in the second category are just notifications: no impact on /dev,
no need to trigger udev rules, and their use will continue to be
extended, and (rarely at the moment) could be frequent (which is no
problem for the existing polling-based mechanism).

> Instead of using uevent for everything, we could go to a separate  
> genetlink for 1-4 instead of making them use uevent like a-d, but we'd  
> end up with two different userspace notification techniques.

We see these as two different categories of notifications, and prefer
the greater flexibility a mechanism independent of uevents would
provide.  The team has discussed several alternatives over the years but
didn't make a decision as we've not yet reached a point where we're
straining the existing mechanism too far.

Alasdair

[toc] | [prev] | [next] | [standalone]

#1495712 — Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On 10/05/2016 02:40 AM, Alasdair G Kergon wrote:
> On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
>> devicemapper is using uevents for:
>> a. dm-verity detected corruption
>> b. dm-multipath: path failed or reinstated
>> c. dm device renamed
>> d. there's also some use in md and bcache.
>>
>> devicemapper uses DM_EVENT ioctl (yuck) for:
>> 1. dm-thin pool data/metadata filling up (hit a threshold)
>> 2. dm-cache is now clean
>> 3. dm-log flushed or log failed
>> 4. dm-raid error detected or sync complete
> 
>> there doesn't seem to be much technical differentiation between the  
>> two lists.
> 
> The distinction in dm is that events in the first category may affect
> the availability of the device: they represent major (and hopefully
> rare) changes.
> 
> Events in the second category are just notifications: no impact on /dev,
> no need to trigger udev rules, and their use will continue to be
> extended, and (rarely at the moment) could be frequent (which is no
> problem for the existing polling-based mechanism).
> 
>> Instead of using uevent for everything, we could go to a separate  
>> genetlink for 1-4 instead of making them use uevent like a-d, but we'd  
>> end up with two different userspace notification techniques.
> 
> We see these as two different categories of notifications, and prefer
> the greater flexibility a mechanism independent of uevents would
> provide.  The team has discussed several alternatives over the years but
> didn't make a decision as we've not yet reached a point where we're
> straining the existing mechanism too far.
> 
I would love to remove the dm-event usage from multipathing.
As it stands using dm-events from multipathing is a massive resource
drain (we have to allocate a waiting thread for each device), and we
more-or-less disregard that information anyway as it is an ex-post
notification made _after_ someone modified the table.
Given that in most cases it was actually _us_ doing the reconfiguration
it has very little value.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

[toc] | [prev] | [next] | [standalone]

#1495719 — Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On Wed, Oct 05, 2016 at 01:40:05AM +0100, Alasdair G Kergon wrote:
> On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
> > devicemapper is using uevents for:
> > a. dm-verity detected corruption
> > b. dm-multipath: path failed or reinstated
> > c. dm device renamed
> > d. there's also some use in md and bcache.
> >
> > devicemapper uses DM_EVENT ioctl (yuck) for:
> > 1. dm-thin pool data/metadata filling up (hit a threshold)
> > 2. dm-cache is now clean
> > 3. dm-log flushed or log failed
> > 4. dm-raid error detected or sync complete
> 
> > there doesn't seem to be much technical differentiation between the  
> > two lists.
> 
> The distinction in dm is that events in the first category may affect
> the availability of the device: they represent major (and hopefully
> rare) changes.
> 
> Events in the second category are just notifications: no impact on /dev,
> no need to trigger udev rules, and their use will continue to be
> extended, and (rarely at the moment) could be frequent (which is no
> problem for the existing polling-based mechanism).
> 
> > Instead of using uevent for everything, we could go to a separate  
> > genetlink for 1-4 instead of making them use uevent like a-d, but we'd  
> > end up with two different userspace notification techniques.
> 
> We see these as two different categories of notifications, and prefer
> the greater flexibility a mechanism independent of uevents would
> provide.  The team has discussed several alternatives over the years but
> didn't make a decision as we've not yet reached a point where we're
> straining the existing mechanism too far.

So, no changes need to be made?  I'm confused here, who is wanting this
changed?

greg k-h

[toc] | [prev] | [next] | [standalone]

#1495970 — Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On 10/04/2016 11:51 PM, Greg KH wrote:
> On Wed, Oct 05, 2016 at 01:40:05AM +0100, Alasdair G Kergon wrote:

>> We see these as two different categories of notifications, and prefer
>> the greater flexibility a mechanism independent of uevents would
>> provide.  The team has discussed several alternatives over the years but
>> didn't make a decision as we've not yet reached a point where we're
>> straining the existing mechanism too far.
>
> So, no changes need to be made?  I'm confused here, who is wanting this
> changed?

Hehe, Alasdair and I are both RH but working on different projects. 
We're not the Borg :)

My project *would* like this added sooner, so I'll work on a revised 
patchset that uses netlink instead of uevents, and will also work on a 
revision to uevents.txt that talks about KOBJ_CHANGE and when it should 
and should not be used, as described by agk, to help out the next person.

Thanks -- Regards -- Andy

[toc] | [prev] | [next] | [standalone]

#1495985 — Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On Wed, Oct 05, 2016 at 10:06:41AM -0700, Andy Grover wrote:
> My project *would* like this added sooner, so I'll work on a revised  
> patchset that uses netlink instead of uevents, and will also work on a  
> revision to uevents.txt that talks about KOBJ_CHANGE and when it should  
> and should not be used, as described by agk, to help out the next person.

netlink might still be overkill for this at this stage, if it's only
making one thread able to monitor multiple devices efficiently.

Let's find out your requirements and see if there's anything different from
the ones we've debated before.

Alasdair

[toc] | [prev] | [next] | [standalone]

#1496101 — Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On 10/05/2016 10:43 AM, Alasdair G Kergon wrote:
> On Wed, Oct 05, 2016 at 10:06:41AM -0700, Andy Grover wrote:
>> My project *would* like this added sooner, so I'll work on a revised
>> patchset that uses netlink instead of uevents, and will also work on a
>> revision to uevents.txt that talks about KOBJ_CHANGE and when it should
>> and should not be used, as described by agk, to help out the next person.
>
> netlink might still be overkill for this at this stage, if it's only
> making one thread able to monitor multiple devices efficiently.
>
> Let's find out your requirements and see if there's anything different from
> the ones we've debated before.

Yeah just like Hannes said, I just want to get dm events for multiple dm 
devices without burning a thread for each device. After your 
clarification, netlink seems like the best option and not overkill.

Give me a few days and I can have something for you to review.

Thanks -- Regards -- Andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web