From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [PATCH] 2.5.x write_super is not for syncing Date: 02 Dec 2002 18:40:44 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1038872444.13527.104.camel@tiny> References: <1034791206.18503.68.camel@tiny> <3DEBD984.BACA3099@digeo.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "linux-fsdevel@vger.kernel.org" Return-path: To: Andrew Morton In-Reply-To: <3DEBD984.BACA3099@digeo.com> List-Id: linux-fsdevel.vger.kernel.org On Mon, 2002-12-02 at 17:07, Andrew Morton wrote: > Except for the s_dirt test in here. If s_dirt is zero and we > have dirty inodes, the filesystem _still_ is not told what to > do. Perhaps dirty inodes imply s_dirt should be true? > > I don't think we'll ever get this right until we start telling the > filesystem what's happening. So instead of all these little > presumptuous micro-syncs which we're doing in there, we need to turn > this inside out and just call sb->s_op->sync_everything_for_umount() > and let the fs decide how to get everything tight on disk. > > That's a bit drastic. At a minimum we need to remove that s_dirt > test and make the commit_super() call unconditional. > > What would that break? Not much, since foofs_commit_super could always check for s_dirt if the local FS really cared. The downside is that since we don't check for s_dirt in commit_supers(), the FS might get sunk twice if the we need to restart at the head of the supers list due to unmount. But, a double sync is possible anyway under FS load in the same situation. -chris