Jan,
> @@ -420,6 +421,8 @@ writeback_single_inode(struct inode *inode, struct bdi_writeback *wb,
> /* Don't write the inode if only I_DIRTY_PAGES was set */
> if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
> int err = write_inode(inode, wbc);
> + if (!err)
> + inode_written = true;
> if (ret == 0)
> ret = err;
> }
write_inode() typically return error after redirtying the inode.
So the conditions inode_written=false and (inode->i_state & I_DIRTY)
are mostly on/off together. For the cases they disagree, it's probably
a filesystem bug -- at least I don't think some FS will deliberately
return success while redirtying the inode, or the reverse.
> } else if (inode->i_state & I_DIRTY) {
> /*
> * Filesystems can dirty the inode during writeback
> * operations, such as delayed allocation during
> * submission or metadata updates after data IO
> - * completion.
> + * completion. Also inode could have been dirtied by
> + * some process aggressively touching metadata.
> + * Finally, filesystem could just fail to write the
> + * inode for some reason. We have to distinguish the
> + * last case from the previous ones - in the last case
> + * we want to give the inode quick retry, in the
> + * other cases we want to put it back to the dirty list
> + * to avoid livelocking of writeback.
> */
> - redirty_tail(inode, wb);
> + if (inode_written)
> + redirty_tail(inode, wb);
Can you elaborate the livelock in the below inode_written=true case?
Why the sleep in the wb_writeback() loop is not enough?
> + else
> + requeue_io(inode, wb);
> } else {
> /*
> * The inode is clean. At this point we either have
Thanks,
Fengguang
--
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
