RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Graham, Simon]

I'm now trying to work through the "internal dependencies and state
changes that need to be adjusted" and it's proving tricky!

First things first though -- I'm assuming that in the case of a failed
resync like this, we really want to end up back in Connected state (but
still inconsistent) rather than simply staying in SyncTarget and
continually trying to resync the affected block; do you agree with this
as a goal?

Assuming that is the case, here's my problem (remember this is based on
0.7 at the moment) -- right now, the check for end-of-resync is done in
w_update_odbm based on the current weight of the bitmap; what's more,
this worker routine is only scheduled from drbd_try_to_clean_on_disk_bm
IF a complete extent is zeroed (and, of course, this routine is only
called from drbd_set_in_sync) -- so simply modifying w_update_odbm to
check if the weight is <= the number of failed blocks will miss a couple
of important cases:
1. If the failure is in the very last block and
2. If the failure is somewhere in the last extent of the on-disk bitmap

Apologies for the detail below, but I want to make sure I'm going about
this the right way - Here's what I'm thinking as a way to fix this --
please comment; you know this code so much better than I do!

1. Add a new field in the mdev - rs_failed - that counts the number of
NegDSReply's received, init to zero 
   at start of resync
2. Move the code that checks for end of resync into a new routine -
drbd_check_for_end_resync() and change it
   to check if the bitmap weight is <= rs_failed.
3. Change drbd_try_to_clean_on_disk_bm to schedule w_update_odbm if
_any_ bits are cleared on disk (perhaps it should
   be some-bit-cleared AND (rs_failed!=0 || extent-now-completely-clear)
- that wont change the current behavior if
   no failures occur -- I'm just a bit worried about doing this too
often...
4. Add a call to drbd_check_for_end_resync() in got_NegDSReply() to
handle the case where the last block failed.
5. Find all the places where rs_total, rs_mark_left and the bitmap
weight are referenced and include rs_failed as
   necessary (e.g. BM_PARANOIA_CHECK in drbd_bitmap.c).

Thanks,
Simon

-----Original Message-----
From: drbd-dev-bounces@linbit.com [mailto:drbd-dev-bounces@linbit.com]
On Behalf Of Lars Ellenberg
Sent: Tuesday, July 04, 2006 11:23 AM
To: drbd-dev@linbit.com; drbd-dev@linbit.com
Subject: Re: [Drbd-dev] Re: [DRBD-user] drbd_panic() in drbd_receiver.c

/ 2006-07-04 11:01:32 -0400
\ Graham, Simon:
> Thanks -- I'm actually starting with drbd 7 just because it's _much_
> easier for me to test (we have a complete build/install/test
> infrastructure currently based on using 0.7) however I will push the
> changes into the head of the trunk as soon as I can.
> 
> FWIW, I have the set-state, NegDReply and NegDSReply stuff coded and
> running; I'm using a known bad disk and no panics so far!

great, send over a svn diff...

> -- the only
> issue I have now is that I think I need to kick the resync processing
> when a NegDSReply is received -- /proc/drbd always shows the resync as
> 100% and stalled;

there are several internal dependencies and state changes that need to
be adjusted...

> BTW: do you have any suggestions for handling the bitmap and meta-data
> write failures?

difficult. we probably need to have several "drbd super blocks" in
drbd8, so we at least have a much higher chance to get important flags
on stable storage _somewhere_. I guess we don't want to have several
bitmaps, but some means to store the "meta data is not reliable anymore"
flag in several places. updates to these blocks have to be
transactional. this is not yet done, but it is on the todo list...


> Also - let me know if you think you would incorporate these changes
into
> the 0.7 branch

unlikely. not impossible, though.

> - if so, I'll send patches (oh and let me know what the
> 'approved' mechanism for sending patches is please).

svn diff

cheers,

-- 
: Lars Ellenberg                                  Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :
_______________________________________________
drbd-dev mailing list
drbd-dev@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-dev

RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Graham, Simon]

Forgot one vital piece -- update drbd_resync_finished to _not_ set the
consistent flag if the bitmap weight is <> 0! (actually, once that's
done, I _think_ all the places that abort resync processing can now
simply call this routine instead of munging the state directly... that
way, all the end-resync processing will always be done (such as
resetting rs_total etc).

/simgr

-----Original Message-----
From: Graham, Simon 
Sent: Tuesday, July 04, 2006 5:35 PM
To: drbd-dev@linbit.com
Cc: Graham, Simon
Subject: RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

I'm now trying to work through the "internal dependencies and state
changes that need to be adjusted" and it's proving tricky!

First things first though -- I'm assuming that in the case of a failed
resync like this, we really want to end up back in Connected state (but
still inconsistent) rather than simply staying in SyncTarget and
continually trying to resync the affected block; do you agree with this
as a goal?

Assuming that is the case, here's my problem (remember this is based on
0.7 at the moment) -- right now, the check for end-of-resync is done in
w_update_odbm based on the current weight of the bitmap; what's more,
this worker routine is only scheduled from drbd_try_to_clean_on_disk_bm
IF a complete extent is zeroed (and, of course, this routine is only
called from drbd_set_in_sync) -- so simply modifying w_update_odbm to
check if the weight is <= the number of failed blocks will miss a couple
of important cases:
1. If the failure is in the very last block and
2. If the failure is somewhere in the last extent of the on-disk bitmap

Apologies for the detail below, but I want to make sure I'm going about
this the right way - Here's what I'm thinking as a way to fix this --
please comment; you know this code so much better than I do!

1. Add a new field in the mdev - rs_failed - that counts the number of
NegDSReply's received, init to zero 
   at start of resync
2. Move the code that checks for end of resync into a new routine -
drbd_check_for_end_resync() and change it
   to check if the bitmap weight is <= rs_failed.
3. Change drbd_try_to_clean_on_disk_bm to schedule w_update_odbm if
_any_ bits are cleared on disk (perhaps it should
   be some-bit-cleared AND (rs_failed!=0 || extent-now-completely-clear)
- that wont change the current behavior if
   no failures occur -- I'm just a bit worried about doing this too
often...
4. Add a call to drbd_check_for_end_resync() in got_NegDSReply() to
handle the case where the last block failed.
5. Find all the places where rs_total, rs_mark_left and the bitmap
weight are referenced and include rs_failed as
   necessary (e.g. BM_PARANOIA_CHECK in drbd_bitmap.c).

Thanks,
Simon

-----Original Message-----
From: drbd-dev-bounces@linbit.com [mailto:drbd-dev-bounces@linbit.com]
On Behalf Of Lars Ellenberg
Sent: Tuesday, July 04, 2006 11:23 AM
To: drbd-dev@linbit.com; drbd-dev@linbit.com
Subject: Re: [Drbd-dev] Re: [DRBD-user] drbd_panic() in drbd_receiver.c

/ 2006-07-04 11:01:32 -0400
\ Graham, Simon:
> Thanks -- I'm actually starting with drbd 7 just because it's _much_
> easier for me to test (we have a complete build/install/test
> infrastructure currently based on using 0.7) however I will push the
> changes into the head of the trunk as soon as I can.
> 
> FWIW, I have the set-state, NegDReply and NegDSReply stuff coded and
> running; I'm using a known bad disk and no panics so far!

great, send over a svn diff...

> -- the only
> issue I have now is that I think I need to kick the resync processing
> when a NegDSReply is received -- /proc/drbd always shows the resync as
> 100% and stalled;

there are several internal dependencies and state changes that need to
be adjusted...

> BTW: do you have any suggestions for handling the bitmap and meta-data
> write failures?

difficult. we probably need to have several "drbd super blocks" in
drbd8, so we at least have a much higher chance to get important flags
on stable storage _somewhere_. I guess we don't want to have several
bitmaps, but some means to store the "meta data is not reliable anymore"
flag in several places. updates to these blocks have to be
transactional. this is not yet done, but it is on the todo list...


> Also - let me know if you think you would incorporate these changes
into
> the 0.7 branch

unlikely. not impossible, though.

> - if so, I'll send patches (oh and let me know what the
> 'approved' mechanism for sending patches is please).

svn diff

cheers,

-- 
: Lars Ellenberg                                  Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :
_______________________________________________
drbd-dev mailing list
drbd-dev@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-dev

Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Philipp Reisner]

Am Dienstag, 4. Juli 2006 23:35 schrieb Graham, Simon:
> I'm now trying to work through the "internal dependencies and state
> changes that need to be adjusted" and it's proving tricky!
>

Hi Simon,

Pleas note that the way we do state changes has dramatically changed
from 0.7 to 8. In 8 we do it finally in a sane way.

> First things first though -- I'm assuming that in the case of a failed
> resync like this, we really want to end up back in Connected state (but
> still inconsistent) rather than simply staying in SyncTarget and
> continually trying to resync the affected block; do you agree with this
> as a goal?
>

Look out for pre_state_checks() in drbd-8. Currently it probably 
does not allow that state.

I have to add that there is a gracefull way of changing state
[ reuqest_state() ] , and a forcefull way [ force_state() ] .

request_state() is usually used by actions that are initiated by 
on operator, while force_state() is used if something fails...

So, if the disk fails during resync you could use force_state()
to go into Connected/Inconsistent, although this is not a valid
state as expressed by the constraints of pre_state_checks().

We need to check that there are no local requests issued to
the not-yet-synced areas. As far as I recall from the back of
my head, drbd-8 drbd_req.c already checks the local disk status
instead of the connection status, but we need to check this.

> Assuming that is the case, here's my problem (remember this is based on
> 0.7 at the moment) --

Hmm, oops, ok.

> right now, the check for end-of-resync is done in 
> w_update_odbm based on the current weight of the bitmap; what's more,
> this worker routine is only scheduled from drbd_try_to_clean_on_disk_bm
> IF a complete extent is zeroed (and, of course, this routine is only
> called from drbd_set_in_sync) -- so simply modifying w_update_odbm to
> check if the weight is <= the number of failed blocks will miss a couple
> of important cases:
> 1. If the failure is in the very last block and
> 2. If the failure is somewhere in the last extent of the on-disk bitmap

I see the issue here. Have to think about it.

> Apologies for the detail below, but I want to make sure I'm going about
> this the right way - Here's what I'm thinking as a way to fix this --
> please comment; you know this code so much better than I do!
>

I will try to answer that part of the mail later today, currently
I am running out of time

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Graham, Simon]

Thanks Philip,

I realize I will have to rework this for DRBD 8 - oh well!

One thing I think is important here is that when an error occurs in the middle of resyncing, I was thinking we should make sure we finish up as much as possible of the resync; this allows the disk to become sane again if the bad block in question is fixed up -- for example, if a subsequent write to the block is done to a bad block and it also allows most accesses to be local if we end up failing over primaryness -- so I was thinking we should not simply abandon the resync as soon as an error is detected... 

On the other hand, perhaps this would be an easier way to handle the issue -- simply abandon the current resync as soon as an error is detected and live with the fact that there are potentially many following blocks that could be synchronized but which will not be -- I suspect this would be much easier to implement in both 7 and 8... I think the only remaining question would then be what the strategy for restarting the resync in this case -- it would be nice if the disk could eventually become consistent again...

I appreciate your guidance and time,
Simon

-----Original Message-----
From: Philipp Reisner [mailto:philipp.reisner@linbit.com] 
Sent: Wednesday, July 05, 2006 4:26 AM
To: drbd-dev@linbit.com
Cc: Graham, Simon
Subject: Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

Am Dienstag, 4. Juli 2006 23:35 schrieb Graham, Simon:
> I'm now trying to work through the "internal dependencies and state
> changes that need to be adjusted" and it's proving tricky!
>

Hi Simon,

Pleas note that the way we do state changes has dramatically changed
from 0.7 to 8. In 8 we do it finally in a sane way.

> First things first though -- I'm assuming that in the case of a failed
> resync like this, we really want to end up back in Connected state (but
> still inconsistent) rather than simply staying in SyncTarget and
> continually trying to resync the affected block; do you agree with this
> as a goal?
>

Look out for pre_state_checks() in drbd-8. Currently it probably 
does not allow that state.

I have to add that there is a gracefull way of changing state
[ reuqest_state() ] , and a forcefull way [ force_state() ] .

request_state() is usually used by actions that are initiated by 
on operator, while force_state() is used if something fails...

So, if the disk fails during resync you could use force_state()
to go into Connected/Inconsistent, although this is not a valid
state as expressed by the constraints of pre_state_checks().

We need to check that there are no local requests issued to
the not-yet-synced areas. As far as I recall from the back of
my head, drbd-8 drbd_req.c already checks the local disk status
instead of the connection status, but we need to check this.

> Assuming that is the case, here's my problem (remember this is based on
> 0.7 at the moment) --

Hmm, oops, ok.

> right now, the check for end-of-resync is done in 
> w_update_odbm based on the current weight of the bitmap; what's more,
> this worker routine is only scheduled from drbd_try_to_clean_on_disk_bm
> IF a complete extent is zeroed (and, of course, this routine is only
> called from drbd_set_in_sync) -- so simply modifying w_update_odbm to
> check if the weight is <= the number of failed blocks will miss a couple
> of important cases:
> 1. If the failure is in the very last block and
> 2. If the failure is somewhere in the last extent of the on-disk bitmap

I see the issue here. Have to think about it.

> Apologies for the detail below, but I want to make sure I'm going about
> this the right way - Here's what I'm thinking as a way to fix this --
> please comment; you know this code so much better than I do!
>

I will try to answer that part of the mail later today, currently
I am running out of time

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Philipp Reisner]

Am Mittwoch, 5. Juli 2006 16:27 schrieb Graham, Simon:
> Thanks Philip,
>
> I realize I will have to rework this for DRBD 8 - oh well!
>
> One thing I think is important here is that when an error occurs in the
> middle of resyncing, I was thinking we should make sure we finish up as
> much as possible of the resync; this allows the disk to become sane again
> if the bad block in question is fixed up -- for example, if a subsequent
> write to the block is done to a bad block and it also allows most accesses
> to be local if we end up failing over primaryness -- so I was thinking we
> should not simply abandon the resync as soon as an error is detected...
>
> On the other hand, perhaps this would be an easier way to handle the issue
> -- simply abandon the current resync as soon as an error is detected and
> live with the fact that there are potentially many following blocks that
> could be synchronized but which will not be -- I suspect this would be much
> easier to implement in both 7 and 8... I think the only remaining question
> would then be what the strategy for restarting the resync in this case --
> it would be nice if the disk could eventually become consistent again...
>
> I appreciate your guidance and time,
> Simon
>

Hi Simon,

Although I am today busy with other things that DRBD and I did not found
a lot of time to think about the problem you want to solve, my gut feeling
is that we should try to finish the resync run, even if there are some
IO errors in the course.

I did not had a look at the code to find out what's easiert to implement
by now.

Currently we simply disconnect from a disk as soon as we see a singe IO
error on it. ( = State transition disk[ UpToDate -> Failed ] )

The question I want to answer first are:
 Should we have a new disk state. ?  PartiallyFailed ?
 No state change at all ?
 Is "PartiallyFailed" the same thing as "Inconsistent" ?
 
Simon, please focus on implementing this for drbd-8. Our current plan
is to have drbd-8 ready by September 2006. (And this might get more
strict that the open-source attitude, it is finished when it is ready ;)

Ok, while thinking about it, I begin to understand how that would feel.
E.g. it would be also allowed to force an degraded cluster (=single
node) with in inconsistent disk to be accessible (=primary) but 
return for all blocks that are out of sync an IO-Error.

Ok, I see, that might be for some cases much more help than the panic,
that DRBD does currently.

I guess that these changes are in the end rather big, and I guess it
is better to not de-stabilize drbd-0.7's code base with such fundamental
changes. This should happen in the development code.

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Philipp Reisner]

> Apologies for the detail below, but I want to make sure I'm going about
> this the right way - Here's what I'm thinking as a way to fix this --
> please comment; you know this code so much better than I do!
>
> 1. Add a new field in the mdev - rs_failed - that counts the number of
> NegDSReply's received, init to zero
>    at start of resync

ack.

> 2. Move the code that checks for end of resync into a new routine -
> drbd_check_for_end_resync() and change it
>    to check if the bitmap weight is <= rs_failed.

ok.

> 3. Change drbd_try_to_clean_on_disk_bm to schedule w_update_odbm if
> _any_ bits are cleared on disk (perhaps it should
>    be some-bit-cleared AND (rs_failed!=0 || extent-now-completely-clear)
> - that wont change the current behavior if
>    no failures occur -- I'm just a bit worried about doing this too
> often...

I see the problem here... And I have am advice for you.
The bm_extent holds the number of dirty bit for the extent (rs_left).
Add a member there that holds the number of IO errors for that
sync extent (rs_failed).
... Do you know by now what I mean ?

> 4. Add a call to drbd_check_for_end_resync() in got_NegDSReply() to
> handle the case where the last block failed.

right.

> 5. Find all the places where rs_total, rs_mark_left and the bitmap
> weight are referenced and include rs_failed as
>    necessary (e.g. BM_PARANOIA_CHECK in drbd_bitmap.c).

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Graham, Simon]

Thanks again for the review; I understand and agree with your comments on doing this in 8 versus 7 - anything I do on 7 will just be for prototyping (because as I said it's much easier for me to test with 7 right now).

I will take the approach of continuing with as much as possible of the resync (although as I suspected, it's MUCH easier to simply abort the resync as soon as any error is reported).

One question -- you said that DRBD disconnects from the disk on the first (local) error -- I think this is only true if you set on-io-error to "Detach" -- we actually run with the default value of PassOn in which case drbd_io_error does nothing; I think this is actually the best way to run since it keeps the disk accessible for those blocks that are OK and returns errors for those that are not.

/simgr

-----Original Message-----
From: drbd-dev-bounces@linbit.com [mailto:drbd-dev-bounces@linbit.com] On Behalf Of Philipp Reisner
Sent: Wednesday, July 05, 2006 12:15 PM
To: drbd-dev@linbit.com
Subject: Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

> Apologies for the detail below, but I want to make sure I'm going about
> this the right way - Here's what I'm thinking as a way to fix this --
> please comment; you know this code so much better than I do!
>
> 1. Add a new field in the mdev - rs_failed - that counts the number of
> NegDSReply's received, init to zero
>    at start of resync

ack.

> 2. Move the code that checks for end of resync into a new routine -
> drbd_check_for_end_resync() and change it
>    to check if the bitmap weight is <= rs_failed.

ok.

> 3. Change drbd_try_to_clean_on_disk_bm to schedule w_update_odbm if
> _any_ bits are cleared on disk (perhaps it should
>    be some-bit-cleared AND (rs_failed!=0 || extent-now-completely-clear)
> - that wont change the current behavior if
>    no failures occur -- I'm just a bit worried about doing this too
> often...

I see the problem here... And I have am advice for you.
The bm_extent holds the number of dirty bit for the extent (rs_left).
Add a member there that holds the number of IO errors for that
sync extent (rs_failed).
... Do you know by now what I mean ?

> 4. Add a call to drbd_check_for_end_resync() in got_NegDSReply() to
> handle the case where the last block failed.

right.

> 5. Find all the places where rs_total, rs_mark_left and the bitmap
> weight are referenced and include rs_failed as
>    necessary (e.g. BM_PARANOIA_CHECK in drbd_bitmap.c).

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :
_______________________________________________
drbd-dev mailing list
drbd-dev@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-dev

Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Philipp Reisner]

Am Mittwoch, 5. Juli 2006 19:49 schrieb Graham, Simon:
> Thanks again for the review; I understand and agree with your comments on
> doing this in 8 versus 7 - anything I do on 7 will just be for prototyping
> (because as I said it's much easier for me to test with 7 right now).
>
> I will take the approach of continuing with as much as possible of the
> resync (although as I suspected, it's MUCH easier to simply abort the
> resync as soon as any error is reported).

Ok. 

> One question -- you said that DRBD disconnects from the disk on the first
> (local) error -- I think this is only true if you set on-io-error to
> "Detach" -- we actually run with the default value of PassOn in which case
> drbd_io_error does nothing; I think this is actually the best way to run
> since it keeps the disk accessible for those blocks that are OK and returns
> errors for those that are not.

Hmmm. The current semantic is:

on-io-error = passOn

If there is a local read error, DRBD will pass the IO error on to the 
filesystem without retrying on the peer node.

Maybe we should have one more on-io-error hander. One that 
retrtries on the peer node, if there is one, and if there is no peer
it returns the IO error, without detaching from the disk.

Good point. 

I added that thought to my ROADMAP file...

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

RE: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

[Graham, Simon]

I agree completely with the idea of having a local failure cause a retry to the peer -- that is actually the subject of the second phase of the work I want to do to handle disk errors -- if a read fails locally because of a bad block, then retry the read remotely AND when the data comes back, actually WRITE it locally as well as returning the result - this will nicely fix the error in a lot of cases as the disk will remap the block.

Of course, there are some tricky timing windows to watch out for here (such as the app performing an explicit write to the same block in the meantime).

/simgr

-----Original Message-----
From: drbd-dev-bounces@linbit.com [mailto:drbd-dev-bounces@linbit.com] On Behalf Of Philipp Reisner
Sent: Thursday, July 06, 2006 10:39 AM
To: drbd-dev@linbit.com
Subject: Re: [Drbd-dev] Re: drbd_panic() in drbd_receiver.c

Am Mittwoch, 5. Juli 2006 19:49 schrieb Graham, Simon:
> Thanks again for the review; I understand and agree with your comments on
> doing this in 8 versus 7 - anything I do on 7 will just be for prototyping
> (because as I said it's much easier for me to test with 7 right now).
>
> I will take the approach of continuing with as much as possible of the
> resync (although as I suspected, it's MUCH easier to simply abort the
> resync as soon as any error is reported).

Ok. 

> One question -- you said that DRBD disconnects from the disk on the first
> (local) error -- I think this is only true if you set on-io-error to
> "Detach" -- we actually run with the default value of PassOn in which case
> drbd_io_error does nothing; I think this is actually the best way to run
> since it keeps the disk accessible for those blocks that are OK and returns
> errors for those that are not.

Hmmm. The current semantic is:

on-io-error = passOn

If there is a local read error, DRBD will pass the IO error on to the 
filesystem without retrying on the peer node.

Maybe we should have one more on-io-error hander. One that 
retrtries on the peer node, if there is one, and if there is no peer
it returns the IO error, without detaching from the disk.

Good point. 

I added that thought to my ROADMAP file...

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :
_______________________________________________
drbd-dev mailing list
drbd-dev@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-dev