All of lore.kernel.org
 help / color / mirror / Atom feed
* mirroring: [patch 5 of 6] device failure tolerance
@ 2005-06-30  8:00 Jonathan E Brassow
  2005-06-30 16:38 ` Kevin Corry
  0 siblings, 1 reply; 8+ messages in thread
From: Jonathan E Brassow @ 2005-06-30  8:00 UTC (permalink / raw)
  To: device-mapper development; +Cc: Kergon Alasdair

This patch changes the status output.  It will break pvmove and other 
things that may have been parsing the status output of a mirror.  It is 
necessary, however, if we are going to have a way to determine which 
device in a mirror failed - or distinguish an failure event from one 
that may simply signal the device is in-sync.  Right now, different 
logs may output different arguments (device and failure, region size, 
sync/nosync, etc), which may make it difficult to parse.  I wondered 
about just having the log type and device with liveness status.  
However, this would still have variable arguments between core and disk 
- or some future scheme that may use multiple log devices for 
redundancy.

  brassow

diff -urN linux-2.6.12-00004/drivers/md/dm-log.c 
linux-2.6.12-00005/drivers/md/dm-log.c
--- linux-2.6.12-00004/drivers/md/dm-log.c	2005-06-30 
01:44:58.277954335 -0500
+++ linux-2.6.12-00005/drivers/md/dm-log.c	2005-06-30 
02:06:43.632391301 -0500
@@ -717,6 +717,9 @@

  	switch(status) {
  	case STATUSTYPE_INFO:
+		DMEMIT("%s %u %u ", log->type->name,
+		       lc->sync == DEFAULTSYNC ? 1 : 2, lc->region_size);
+		DMEMIT_SYNC;
  		break;

  	case STATUSTYPE_TABLE:
@@ -737,6 +740,14 @@

  	switch(status) {
  	case STATUSTYPE_INFO:
+		format_dev_t(buffer, lc->log_dev->bdev->bd_dev);
+		DMEMIT("%s %u %s%s %u ",
+		       log->type->name,
+		       lc->sync == DEFAULTSYNC ? 2 : 3,
+		       buffer,
+		       lc->log_dev_failed ? "/D" : "/A",
+		       lc->region_size);
+		DMEMIT_SYNC;
  		break;

  	case STATUSTYPE_TABLE:
diff -urN linux-2.6.12-00004/drivers/md/dm-raid1.c 
linux-2.6.12-00005/drivers/md/dm-raid1.c
--- linux-2.6.12-00004/drivers/md/dm-raid1.c	2005-06-30 
01:56:19.457727576 -0500
+++ linux-2.6.12-00005/drivers/md/dm-raid1.c	2005-06-30 
01:56:27.164784984 -0500
@@ -1546,8 +1546,11 @@
  	switch (type) {
  	case STATUSTYPE_INFO:
  		DMEMIT("%d ", ms->nr_mirrors);
-		for (m = 0; m < ms->nr_mirrors; m++)
-			DMEMIT("%s ", ms->mirror[m].dev->name);
+		for (m = 0; m < ms->nr_mirrors; m++) {
+			DMEMIT("%s/%s ", ms->mirror[m].dev->name,
+			       atomic_read(&(ms->mirror[m].error_count)) ?
+			       "D" : "A");
+		}

  		DMEMIT(SECTOR_FORMAT "/" SECTOR_FORMAT,
  		       ms->rh.log->type->get_sync_count(ms->rh.log),

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30  8:00 mirroring: [patch 5 of 6] device failure tolerance Jonathan E Brassow
@ 2005-06-30 16:38 ` Kevin Corry
  2005-06-30 17:56   ` Alasdair G Kergon
  0 siblings, 1 reply; 8+ messages in thread
From: Kevin Corry @ 2005-06-30 16:38 UTC (permalink / raw)
  To: dm-devel; +Cc: Kergon Alasdair

Hi Jonathan,

On Thu June 30 2005 3:00 am, Jonathan E Brassow wrote:
> This patch changes the status output.  It will break pvmove and other
> things that may have been parsing the status output of a mirror.

Any time a target's table-format or status-format changes, we also need to 
increment that target's version number so user-space can figure out which 
format to expect.

The version for dm-mirror is currently 1.0.1, so we should at least bump it to 
1.0.2 or 1.1.0.

Also, please remember to turn off line-wrap when inserting patches into 
emails.  :)

Thanks,
-- 
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/


--- dm-raid1.c.old 2005-06-30 11:33:24.000000000 -0500
+++ dm-raid1.c 2005-06-30 11:33:34.000000000 -0500
@@ -1210,7 +1210,7 @@
 
 static struct target_type mirror_target = {
  .name  = "mirror",
- .version = {1, 0, 1},
+ .version = {1, 1, 0},
  .module  = THIS_MODULE,
  .ctr  = mirror_ctr,
  .dtr  = mirror_dtr,

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30 16:38 ` Kevin Corry
@ 2005-06-30 17:56   ` Alasdair G Kergon
  2005-06-30 18:00     ` Kevin Corry
  2005-06-30 18:10     ` Jonathan E Brassow
  0 siblings, 2 replies; 8+ messages in thread
From: Alasdair G Kergon @ 2005-06-30 17:56 UTC (permalink / raw)
  To: Kevin Corry; +Cc: dm-devel

On Thu, Jun 30, 2005 at 11:38:28AM -0500, Kevin Corry wrote:
> Any time a target's table-format or status-format changes, we also need to 
> increment that target's version number so user-space can figure out which 
> format to expect.
 
Indeed, but I don't want version numbers updating till we know what
sequence things will go upstream.

BTW I've not seen a justification for breaking the existing format here
yet as opposed to simply appending new data to the end of the status line.

Alasdair
-- 
agk@redhat.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30 17:56   ` Alasdair G Kergon
@ 2005-06-30 18:00     ` Kevin Corry
  2005-06-30 18:10     ` Jonathan E Brassow
  1 sibling, 0 replies; 8+ messages in thread
From: Kevin Corry @ 2005-06-30 18:00 UTC (permalink / raw)
  To: Alasdair G Kergon; +Cc: dm-devel

On Thu June 30 2005 12:56 pm, Alasdair G Kergon wrote:
> On Thu, Jun 30, 2005 at 11:38:28AM -0500, Kevin Corry wrote:
> > Any time a target's table-format or status-format changes, we also need
> > to increment that target's version number so user-space can figure out
> > which format to expect.
>
> Indeed, but I don't want version numbers updating till we know what
> sequence things will go upstream.

Of course. As long as it gets updated before it hits mainline. :)

-- 
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30 17:56   ` Alasdair G Kergon
  2005-06-30 18:00     ` Kevin Corry
@ 2005-06-30 18:10     ` Jonathan E Brassow
  2005-06-30 18:58       ` Alasdair G Kergon
  2005-06-30 19:05       ` Jonathan E Brassow
  1 sibling, 2 replies; 8+ messages in thread
From: Jonathan E Brassow @ 2005-06-30 18:10 UTC (permalink / raw)
  To: Kergon Alasdair, device-mapper development


On Jun 30, 2005, at 12:56 PM, Alasdair G Kergon wrote:

> On Thu, Jun 30, 2005 at 11:38:28AM -0500, Kevin Corry wrote:
>> Any time a target's table-format or status-format changes, we also 
>> need to
>> increment that target's version number so user-space can figure out 
>> which
>> format to expect.
>
> Indeed, but I don't want version numbers updating till we know what
> sequence things will go upstream.
>
> BTW I've not seen a justification for breaking the existing format here
> yet as opposed to simply appending new data to the end of the status 
> line.
>

mirror_status first calls the log status function and then adds on to 
that.  If we want to do what you are proposing, we would move the log 
status function _after_ the DMEMIT's for mirror and it would only print 
out a char for each log device indicating status.  We would have to 
remember that STATUSTYPE_INFO and STATUSTYPE_TABLE would call the log 
status function at different place (one after it's own DMEMITs, the 
other before).

  brassow

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30 18:10     ` Jonathan E Brassow
@ 2005-06-30 18:58       ` Alasdair G Kergon
  2005-06-30 19:05       ` Jonathan E Brassow
  1 sibling, 0 replies; 8+ messages in thread
From: Alasdair G Kergon @ 2005-06-30 18:58 UTC (permalink / raw)
  To: Jonathan E Brassow; +Cc: device-mapper development

On Thu, Jun 30, 2005 at 01:10:04PM -0500, Jon Brassow wrote:
> mirror_status first calls the log status function and then adds on to 
> that.  If we want to do what you are proposing, we would move the log 
> status function _after_ the DMEMIT's for mirror and it would only print 
> out a char for each log device indicating status.  We would have to 
> remember that STATUSTYPE_INFO and STATUSTYPE_TABLE would call the log 
> status function at different place (one after it's own DMEMITs, the 
> other before).
 
Backwards compatibility has to take precedence over tidiness here if you
want these patches including quickly.  If you don't mind waiting several
months while the necessary userspace support gets widely propagated,
then we can indeed tidy things up now.  But I'm not prepared to see
device-mapper kernel incompatibilities go in ahead of the userspace 
preparation.

Alasdair
-- 
agk@redhat.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30 18:10     ` Jonathan E Brassow
  2005-06-30 18:58       ` Alasdair G Kergon
@ 2005-06-30 19:05       ` Jonathan E Brassow
  2005-06-30 19:51         ` Alasdair G Kergon
  1 sibling, 1 reply; 8+ messages in thread
From: Jonathan E Brassow @ 2005-06-30 19:05 UTC (permalink / raw)
  To: device-mapper development

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]


On Jun 30, 2005, at 1:10 PM, Jonathan E Brassow wrote:

>
> On Jun 30, 2005, at 12:56 PM, Alasdair G Kergon wrote:
>
>> On Thu, Jun 30, 2005 at 11:38:28AM -0500, Kevin Corry wrote:
>>> Any time a target's table-format or status-format changes, we also 
>>> need to
>>> increment that target's version number so user-space can figure out 
>>> which
>>> format to expect.
>>
>> Indeed, but I don't want version numbers updating till we know what
>> sequence things will go upstream.
>>
>> BTW I've not seen a justification for breaking the existing format 
>> here
>> yet as opposed to simply appending new data to the end of the status 
>> line.
>>
>
> mirror_status first calls the log status function and then adds on to 
> that.  If we want to do what you are proposing, we would move the log 
> status function _after_ the DMEMIT's for mirror and it would only 
> print out a char for each log device indicating status.  We would have 
> to remember that STATUSTYPE_INFO and STATUSTYPE_TABLE would call the 
> log status function at different place (one after it's own DMEMITs, 
> the other before).
>

Perhaps like the attached patch.

I think the pvmove stuff is already busted.  How does it handle mirrors 
with more than 2 sides?  (ok, so pvmove isn't broken, but code that 
uses the same function to determine a mirrors status would be - lvs?)  
If we are going to add code that must correctly handle the number of 
mirror args, I think we could add code to properly handle the log args 
at the same time.  Then we have some (limited) flexibility in how 
things are handled.

  brassow


[-- Attachment #2: 00005-alt.patch --]
[-- Type: application/octet-stream, Size: 1882 bytes --]

diff -urN linux-2.6.12-00004/drivers/md/dm-log.c linux-2.6.12-00005-alt/drivers/md/dm-log.c
--- linux-2.6.12-00004/drivers/md/dm-log.c	2005-06-30 01:44:58.000000000 -0500
+++ linux-2.6.12-00005-alt/drivers/md/dm-log.c	2005-06-30 13:46:43.260023309 -0500
@@ -737,6 +737,8 @@
 
 	switch(status) {
 	case STATUSTYPE_INFO:
+		format_dev_t(buffer, lc->log_dev->bdev->bd_dev);
+		DMEMIT("%s %c", buffer, lc->log_dev_failed ? 'D' : 'A');
 		break;
 
 	case STATUSTYPE_TABLE:
diff -urN linux-2.6.12-00004/drivers/md/dm-raid1.c linux-2.6.12-00005-alt/drivers/md/dm-raid1.c
--- linux-2.6.12-00004/drivers/md/dm-raid1.c	2005-06-30 01:56:19.000000000 -0500
+++ linux-2.6.12-00005-alt/drivers/md/dm-raid1.c	2005-06-30 13:55:18.644187058 -0500
@@ -1538,23 +1538,28 @@
 static int mirror_status(struct dm_target *ti, status_type_t type,
 			 char *result, unsigned int maxlen)
 {
-	unsigned int m, sz;
+	unsigned int m, sz = 0;
 	struct mirror_set *ms = (struct mirror_set *) ti->private;
-
-	sz = ms->rh.log->type->status(ms->rh.log, type, result, maxlen);
+	char buffer[ms->nr_mirrors + 1];
 
 	switch (type) {
 	case STATUSTYPE_INFO:
 		DMEMIT("%d ", ms->nr_mirrors);
-		for (m = 0; m < ms->nr_mirrors; m++)
+		for (m = 0; m < ms->nr_mirrors; m++) {
 			DMEMIT("%s ", ms->mirror[m].dev->name);
+			buffer[m] = atomic_read(&(ms->mirror[m].error_count)) ? 
+				'D' : 'A';
+		}
+		buffer[m] = '\0';
 
-		DMEMIT(SECTOR_FORMAT "/" SECTOR_FORMAT,
+		DMEMIT(SECTOR_FORMAT "/" SECTOR_FORMAT " %s ",
 		       ms->rh.log->type->get_sync_count(ms->rh.log),
-		       ms->nr_regions);
+		       ms->nr_regions, buffer);
+		ms->rh.log->type->status(ms->rh.log, type, result+sz, maxlen-sz);
 		break;
 
 	case STATUSTYPE_TABLE:
+		sz = ms->rh.log->type->status(ms->rh.log, type, result, maxlen);
 		DMEMIT("%d ", ms->nr_mirrors);
 		for (m = 0; m < ms->nr_mirrors; m++)
 			DMEMIT("%s " SECTOR_FORMAT " ",

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]



[-- Attachment #4: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: mirroring: [patch 5 of 6] device failure tolerance
  2005-06-30 19:05       ` Jonathan E Brassow
@ 2005-06-30 19:51         ` Alasdair G Kergon
  0 siblings, 0 replies; 8+ messages in thread
From: Alasdair G Kergon @ 2005-06-30 19:51 UTC (permalink / raw)
  To: device-mapper development

On Thu, Jun 30, 2005 at 02:05:29PM -0500, Jon Brassow wrote:
> I think the pvmove stuff is already busted.  How does it handle mirrors 
> with more than 2 sides?  

It only has to handle 2 devices.

> (ok, so pvmove isn't broken, 

Correct.  No compatibility problems there.

> code that 
> uses the same function to determine a mirrors status would be - lvs?)  

But that can easily be enhanced when needed.

Alasdair
-- 
agk@redhat.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-06-30 19:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-30  8:00 mirroring: [patch 5 of 6] device failure tolerance Jonathan E Brassow
2005-06-30 16:38 ` Kevin Corry
2005-06-30 17:56   ` Alasdair G Kergon
2005-06-30 18:00     ` Kevin Corry
2005-06-30 18:10     ` Jonathan E Brassow
2005-06-30 18:58       ` Alasdair G Kergon
2005-06-30 19:05       ` Jonathan E Brassow
2005-06-30 19:51         ` Alasdair G Kergon

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.