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
