On 10/22/2015 06:20 AM, Ilya Dryomov wrote: > >> > >> > If we are just talking about if stable pages are not used, and someone >> > is re-writing data to a page after the page has already been submitted >> > to the block layer (I mean the page is on some bio which is on a request >> > which is on some request_queue scheduler list or basically anywhere in >> > the block layer), then I was saying this can occur with any block >> > driver. There is nothing that is preventing this from happening with a >> > FC driver or nvme or cciss or in dm or whatever. The app/user can >> > rewrite as late as when we are in the make_request_fn/request_fn. >> > >> > I think I am misunderstanding your question because I thought this is >> > expected behavior, and there is nothing drivers can do if the app is not >> > doing a flush/sync between these types of write sequences. > I don't see a problem with rewriting as late as when we are in > request_fn() (or in a wq after being put there by request_fn()). Where > I thought there *might* be an issue is rewriting after sendpage(), if > sendpage() is used - perhaps some sneaky sequence similar to that > retransmit bug that would cause us to *transmit* incorrect bytes (as > opposed to *re*transmit) or something of that nature? Just to make sure we are on the same page. Are you concerned about the tcp/net layer retransmitting due to it detecting a issue as part of the tcp protocol, or are you concerned about rbd/libceph initiating a retry like with the nfs issue? -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
