xfs
[Top] [All Lists]

Re: [PATCH-v4 6/7] ext4: add support for a lazytime mount option

To: Jan Kara <jack@xxxxxxx>
Subject: Re: [PATCH-v4 6/7] ext4: add support for a lazytime mount option
From: Theodore Ts'o <tytso@xxxxxxx>
Date: Thu, 27 Nov 2014 15:13:16 -0500
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Andreas Dilger <adilger@xxxxxxxxx>, Linux Filesystem Development List <linux-fsdevel@xxxxxxxxxxxxxxx>, Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx>, Linux btrfs Developers List <linux-btrfs@xxxxxxxxxxxxxxx>, XFS Developers <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Dr5VIJ12LTt8MH9Uz8w1PrTeDGh6BOAz8aueFfHhZIM=; b=l6ASwwAQ9+f/1OpPssiTLH/lxtVRE1yxjiQh13WpxY9NJxNLmnG9tI5eQmdRJKnMecXF5b30fwuByoRdADW5snbbdtVOyXDl0Cj1HjEmOrww1qRAsBsGm49ocbFwgGl6D+C2xK43EVgFZRacHBmxnAUBRdVgMG1+CSnRhvUHnaU=;
In-reply-to: <20141127154159.GA11922@xxxxxxxxxxxxx>
References: <1416997437-26092-1-git-send-email-tytso@xxxxxxx> <1416997437-26092-7-git-send-email-tytso@xxxxxxx> <20141126224843.GG9561@dastard> <1A106262-D64C-4493-856F-AAAFC3BE2647@xxxxxxxxx> <20141126233537.GH9561@dastard> <20141127132752.GF30152@xxxxxxxxxxxxx> <20141127133227.GA11872@xxxxxxxxxxxxx> <20141127152524.GB14091@xxxxxxxxx> <20141127154159.GA11922@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
On Thu, Nov 27, 2014 at 04:41:59PM +0100, Jan Kara wrote:
>   Hum, but this puts lots of stuff under inode_hash_lock, including
> writeback list lock. I don't like this too much. I understand that getting
> handle for each inode is rather more CPU intensive but it should still be a
> clear win over the current situation and avoids entangling locks like this.

Hmm, if we dropped the inode_requeue_dirtytime(), then we can avoid
taking the writeback list lock.  The net result is that we would have
some inodes still on the b_dirty_time list that were no longer
I_DIRTY_TIME, but since I_DIRTY_TIME wouldn't be set, it's mostly
harmless since when we do iterate over the b_dirty_time list, those
inodes can be quickly identified and skipped over.  (And if the inode
ever gets dirtied for real, then it will get moved onto the b_dirty
list and that will be that.)

The problem with getting a handle on the inode is not just that it is
more CPU intensive, but that can't let the iput_final() call happen
until after we have finished the transaction handle.  We could keep a
linked list of inodes attached to the handle, and then only call iput
on them once ext4_journal_stop(handle) gets called, but that's a
complication I'd like to avoid if at all possible.

Being able to opporunistically write the timestamps when we are
journalling an inode table block is a pretty big win, so if we end up
extending the hold time on inode_hash_lock (only when we come across a
I_DIRTY_TIME inode that we can clear) a tiny bit, there will be a lot
of workloads where I think it's a worthwhile tradeoff.  If we can
avoid entangling the writebakc list lock, does that make you happier
about this approach?

                                         - Ted

<Prev in Thread] Current Thread [Next in Thread>