[Top] [All Lists]

Re: [PATCH 08/13] xfs: xfs_sync_fsdata is redundant

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 08/13] xfs: xfs_sync_fsdata is redundant
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Tue, 04 Sep 2012 15:59:36 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1346328017-2795-9-git-send-email-david@xxxxxxxxxxxxx>
References: <1346328017-2795-1-git-send-email-david@xxxxxxxxxxxxx> <1346328017-2795-9-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 08/30/12 07:00, Dave Chinner wrote:
From: Dave Chinner<dchinner@xxxxxxxxxx>

Why do we need to write the superblock to disk once we've written
all the data?  We don't actually - the reasons for doing this are
lost in the mists of time, and go back to the way Irix used to drive
VFS flushing.

On linux, this code is only called from two contexts: remount and
.sync_fs. In the remount case, the call is followed by a metadata
sync, which unpins and writes the superblock.  In the sync_fs case,
we only need to force the log to disk to ensure that the superblock
is correctly on disk, so we don't actually need to write it. Hence
the functionality is either redundant or superfluous and thus can be

Seeing as xfs_quiesce_data is essentially now just a log force,
remove it as well and fold the code back into the two callers.
Neither of them need the log covering check, either, as that is
redundant for the remount case, and unnecessary for the .sync_fs

Signed-off-by: Dave Chinner<dchinner@xxxxxxxxxx>

Looks good.

Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>

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