On Fri, 4 Aug 2006 15:27:21 -0400
Chris Mason <mason@xxxxxxxx> wrote:
> /*
> + * starts IO on any dirty blocks in the block device. This uses
> + * filemap_flush, and so it does not wait for the io to finish, and does
> + * not wait on any IO currently in flight.
> + */
> +void writeback_bdev(struct super_block *sb)
> +{
> + struct address_space *mapping = sb->s_bdev->bd_inode->i_mapping;
> + filemap_flush(mapping);
> +}
> +EXPORT_SYMBOL_GPL(writeback_bdev);
> +
> +/*
> + * start writeback on both the inode and the data blocks.
> + * filemap_fdatawrite is used, so it waits for any IO that was in
> + * flight for dirty blocks at the start of this call. This will not
> + * wait for any IO it starts.
> + */
> +void writeback_inode(struct inode *inode)
> +{
> +
> + struct address_space *mapping = inode->i_mapping;
> + struct writeback_control wbc = {
> + .sync_mode = WB_SYNC_NONE,
> + .nr_to_write = 0,
> + };
> + /* if we used WB_SYNC_ALL, sync_inode waits for the io for the
> + * inode to finish. So WB_SYNC_NONE is sent down to sync_inode
> + * and filemap_fdatawrite is used for the data blocks
> + */
> + sync_inode(inode, &wbc);
> + filemap_fdatawrite(mapping);
> +}
> +EXPORT_SYMBOL_GPL(writeback_inode);
Could we have more detail on what you're trying to do here?
You've obviously made some decisions about how to handle under-writeback
data, dirty data, integrity versus cleaning, etc. What were those
decisions and what led you to them?
We should document the precise semantics of these two functions, especially
wrt data integrity, handling of dirty-but-under-writeback pages, etc.
(Right now I'm not sure what those semantics are).
I'm also wondering what sync_inode(nr_to_write=0) does ;) I think it writes
one page...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
