-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't return an error on unmap while rebuilding #1008
Don't return an error on unmap while rebuilding #1008
Conversation
Longhorn 7103 Signed-off-by: Eric Weber <eric.weber@suse.com>
To test: Follow steps 1-8 in the reproduce: longhorn/longhorn#7103 (comment). Then:
|
End-to-end testing: https://ci.longhorn.io/job/private/job/longhorn-tests-regression/6189/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general LGTM
// This is a legitimate error (which is handled by tgt/liblonghorn at a higher level). Since tgt/liblonghorn | ||
// does not actually print the error, print it here. | ||
err := fmt.Errorf("EOF: unmap of %v bytes at offset %v is beyond volume size %v", length, off, c.size) | ||
logrus.WithError(err).Error("Failed to unmap") | ||
c.RUnlock() | ||
return 0, err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: return 0, io.ErrUnexpectedEOF
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm likely fine with this, but can you help clarify the goal here, as I am new to the conventions in this code. If we return io.ErrUnexpectedEOF
here, it will end up in:
longhorn-engine/pkg/dataconn/server.go
Lines 110 to 120 in 341436e
msg.Type = TypeResponse | |
if err == io.EOF { | |
msg.Type = TypeEOF | |
msg.Data = msg.Data[:count] | |
msg.Size = uint32(len(msg.Data)) | |
} else if err != nil { | |
msg.Type = TypeError | |
msg.Data = []byte(err.Error()) | |
msg.Size = uint32(len(msg.Data)) | |
} | |
s.responses <- msg |
We will just treat it like any other error and push it back to liblonghorn with msg.Type == TypeError
instead of msg.Type == TypeEOF
. Is that the intention, or do we need to make additional changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
longhorn-engine/pkg/dataconn
is the data transfer service between engine and replicas. The results are handled by engine like this.
While the error in longhorn-engine/pkg/controller/control
will be returned to the frontend iscsi layer.
This is a NIT suggestion anyway. I am fine with the existing implementation.
err := fmt.Errorf("cannot unmap %v bytes at offset %v while rebuilding is in progress", length, off) | ||
logrus.WithError(err).Warn("Failed to unmap") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: logrus.Warnf()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can do in a followup. I was mostly just going for consistency with the other cases.
✅ Backports have been created
|
@mergify backport v1.4.x |
✅ Backports have been created
|
Longhorn 7103
Which issue(s) this PR fixes:
longhorn/longhorn#7103
What this PR does / why we need it:
Don't return an error to tgt/liblonghorn when UNMAP is called during a rebuild. We are not required to do so, and doing so causes harvester/harvester#4739.