of course I described what happens under the bdev semaphore at the very
latest release, so there is no "two" opener case here. If some reference
of the file is still open I don't even attempt to sync anything. (if the
user didn't asked for O_SYNC of course, in such a case the
generic_file_write would take care of it)
> data after the first one has done __block_fsync? And the truncate will
> throw the dirtied page away?
There can't be any truncate because the blkdev isn't a regular file.
> Now, I don't think we need to be _too_ careful about cache coherency: it's
> probably ok to do something like
>
> __block_fsync(dev) - sync _our_ changes
> invalidate_inode_pages(dev) - this will only invalidate unused pages
> invalidate_device(dev)
that's definitely not enough, see the other issue mentioned by Andreas
in this thread, the reason I wrote the algorithm I explained in the
previous email is as first thing to eventually avoid infinite long fsck
of the root fs.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/