On Fri, Aug 2, 2013 at 5:10 PM, neha naik <nehanaik27@xxxxxxxxx> wrote: > Thanks for the responses. I have one more question for Greg. I come from > filesystem background and not device driver so i may be a bit confused > about the write order fidelity. I know that filesystems guarantee that. > Looking from filesystem perspective, no write will be allowed on the same > block until > the first write finishes. So, if 'B' is written after 'A' you can always > guarantee that you will see 'B' at the end of the two writes. I see what you are saying and that is totally different from what I was talking about. I am saying if userspace does: lseek(location_A), write(data_A) lseek(location_B), write(data_B) There is no guarantee which of those writes will be delivered to the device driver to perform first. The block layer has elevator logic that can optimize the physical write order. > Now imagine not having a filesystem, and doing a write directly on the > device. Do device drivers honour it. Should they? I imagine device driver as > a kind of > queue. So any writes are always queued up one after the other so that it > gives write order fidelity whether it wants to or not. Am i missing > something here. You seem to be talking about: lseek(location_A), write(data_A) lseek(location_A), write(data_B) That is a very special case and there is special logic to ensure data_B is the final write. So if you are only talking/thinking about overwrites of the exact same location, then you need to appreciate and clarify that you are talking about a special case. In the overwrite case, I believe the first write (data_A) can simply be consumed by the second write (data_B) and never even make it to the device driver. If it does get to the device driver, the disk drive might consolidate them to a single write of data_B to media. > Regards, > Neha Greg _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
