From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: Lazytime feature bugs
Date: Mon, 2 Mar 2015 09:29:07 +0100 [thread overview]
Message-ID: <20150302082907.GA4199@quack.suse.cz> (raw)
In-Reply-To: <20150226192735.GB17174@thunk.org>
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@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2015-03-02 8:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 13:19 Lazytime feature bugs Jan Kara
2015-02-24 18:31 ` Jan Kara
2015-02-24 18:58 ` Linus Torvalds
2015-02-25 14:52 ` Theodore Ts'o
2015-02-25 16:25 ` Jan Kara
2015-02-26 4:33 ` Theodore Ts'o
2015-02-26 8:34 ` Jan Kara
2015-02-26 13:45 ` Theodore Ts'o
2015-02-26 14:38 ` Jan Kara
2015-02-26 19:27 ` Theodore Ts'o
2015-03-02 8:29 ` Jan Kara [this message]
2015-03-07 5:34 ` [PATCH] fs: make sure the timestamps for lazytime inodes eventually get written Theodore Ts'o
2015-03-08 10:06 ` Jan Kara
2015-03-08 19:06 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302082907.GA4199@quack.suse.cz \
--to=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).