On Mon, Jun 30 2008, Zhao Forrest wrote: > > > > Don't forget that all IO requests are queued on the device. With a > > modern HW and disk you usually have NCQ and most drives will throw > > away write request to the same sector if they see a later write to > > the same sector in the queue. > > > > That said. There is nothing wrong with writing again and again to > > the same sector on disk. File/record locking is done at the FileSystem > > level. An application that wants exclusive write need to open the file > > that way. Other wise it could even be written from another machine not > > even another thread. > > > > What is it you are concerned with? > > > I happen to read the email and have a question, that may not be Erez's > real question :) > Let's suppose the following example: > 1 pdflush find a dirty inode and decides to flush a set of dirty pages > to harddrive > 2 while this set of dirty pages is being committed to > harddrive(dma_mapping is done, but dirty pages are not really written > to disk media), application/FS is trying to update some pages in this > set of dirty pages. > > Then what happens? Will application be put into sleep until page > flushing to disk media is done? Yes, the page needs to be locked before IO can be issued. So it'll block on the page lock. That is what I referred to as the page cache providing this guarentee for you. With raw IO, the application needs to ensure ordering on its own if it commits IO to the same block more than once. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
