On Thu 26-02-15 14:27:35, Ted Tso wrote:
> On Thu, Feb 26, 2015 at 03:38:28PM +0100, Jan Kara wrote:
> > But you wrote you'll reset i_dirty_time_when to "now" when queueing into
> > b_dirty_time. Thus frequently dirtied inodes will just travel back and
> > forth between b_dirty and b_dirty_time lists and i_dirty_time will be
> > continuously reset. And you never end up writing it. That's why I suggested
> > to reset i_dirted_when instead (since it would be unused in b_dirty_time
> > list anyway).
>
> Inodes will never get transfered onto the b_dirty_time list if they
> also have dirty pages. So if the inode is constantly getting dirtied,
> the pages *will* get written out, and when they do, we'll also check
> to see if i_dirty_time_when is too old, and also updated the
> timestamp.
>
> Basically the I_DIRTY_TIME flag is the "weakest" of all of the dirty
> flags. If the inode is dirty, it takes precedence, and writing out
> the inode will include updating the timestamps. If the inode's pages
> are dirty, it takes precedence over I_DIRTY_TIME, so we worry about
> getting the pages written out before we even think about considering
> whether or not the inode should go on the b_dirty_time list.
>
> So I don't see how inodes would be shuttling back and forth between
> b_io and b_dirty_time.
So maybe I miss something but I still don't see what prevents this
scenario:
1) write to file happens -> inode timestamps updated, inode filed to b_dirty,
i_dirtied_when = now, i_dirty_time_when = now
2) writeback for file happens, all pages written but not timestamps since
they are fresh -> inode gets filed to b_dirty_time list, if we use your
algorithm, i_dirty_time_when = now.
3) write to file happens -> inode filed to b_dirty, i_dirtied_when = now.
4) goto 2)
Now the loop in the above can happen infinitely long and you never end up
writing inode because time stamps are updated on write to file and
i_dirty_time_when gets updated when you move inode to b_dirty_time list.
Again if there's a fault in the above logic or I misunderstood something
from your proposal, I'm happy to be corrected.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
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
