fix linux p9fs multi message reads #932
Conversation
|
The code changes seem sensible to me, but I don't have a lot of context around p9fs or filesystem implementations in general, so I don't know whether this is the right thing to do semantically |
| std::cmp::min(space_left, (metadata.len() - msg.offset) as usize); | ||
|
|
||
| p9_write_file(&file, chain, mem, buflen, msg.offset as i64); | ||
| let space_left = u64::from(msize) |
There was a problem hiding this comment.
The space left for a p9fs message needs to be computed in terms of the maximum message size (msize in p9fs parlance), and not the read count from the client.
There was a problem hiding this comment.
taking this as an excuse to learn about p9fs, this is more like MAX_READ_SIZE now right? e.g. given the current msize, a read can safely be satisfied with up to this many bytes.
then the issue before was that if a client asked to read, say, 20 bytes, we'd calculate we could only return 9?
There was a problem hiding this comment.
yes, that's correct
| std::cmp::min(space_left, (metadata.len() - msg.offset) as usize); | ||
|
|
||
| p9_write_file(&file, chain, mem, buflen, msg.offset as i64); | ||
| let space_left = u64::from(msize) |
There was a problem hiding this comment.
taking this as an excuse to learn about p9fs, this is more like MAX_READ_SIZE now right? e.g. given the current msize, a read can safely be satisfied with up to this many bytes.
then the issue before was that if a client asked to read, say, 20 bytes, we'd calculate we could only return 9?
The p9fs stuff is behind the |
ah i'd forgotten it was fully sequestered like that, fair enough |
Uh oh!
There was an error while loading. Please reload this page.