Thomas Petazzoni escreveu: ...
Paulo was probably referring to I/O barriers, as described in Documentation/block/barrier.txt.
Yes, that's the point ...
However, I'm not sure I understand Paulo's request properly. Issuing an I/O barrier is simply a matter of issuing a bio structure with the BIO_RW_BARRIER flag set in the bi_rw field of the bio structure.
I am confused about all this I/O stuff ... Let me see: 1. When I submit a submit_bio (write) and pass it a callback function foo (bio->bi_end_io=foo), when foo is reached the submited bio is on disk; 2. If, on the previous operation, bio->bi_rw=WRITE|BIO_RW_BARRIER then when foo is reached all previous writes, including the last one are complete; Now the problems. What happens when buffers are involved? 1. I need to write a single buffer (bh) to disk, but only after *all previously* submited sumit_bio's are complete. Do I need to to use bio->bi_rw=WRITE|BIO_RW_BARRIER on the last submit_bio and then use mark_buffer_dirty(bh); sync_dirty_buffer(bh); or is it enough to issue mark_buffer_dirty(bh); sync_dirty_buffer(bh); ? 2. A more complex situation ... I have two sets of blocks on disk. Set A: The blocks were to be written at random places, and practically never on the same places, but always before any of the blocks of set B. There may be various Sets A. Set B: The blocks are all contiguous on disk and some of then (dirty ones) must be written to their "places" on disk but after all blocks of given Set A were written. There is only a Set B. Correct me if I am wrong ... For Set A, I use "normal" alocated pages and use submit_bio to write them. For Set B, I think of using buffer pages. Now the problems: How do I prevent Set B dirty pages to be written to disk, by the kernel, before the Set A is complete? How do I "flush" Set B (write all dirty pages) assuring that the operation is complete before I could proceed with another Set A writes? sync_mapping_buffers is enough? Sorry for asking this, but I need to clear up my mind about it. In the meanwhile I'm going to continue digging in the sources ... Thanks -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
