From owner-freebsd-current  Tue Sep 22 15:42:32 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA20356
          for freebsd-current-outgoing; Tue, 22 Sep 1998 15:42:32 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20264
          for <current@FreeBSD.ORG>; Tue, 22 Sep 1998 15:42:15 -0700 (PDT)
          (envelope-from luoqi@watermarkgroup.com)
Received: (from luoqi@localhost)
	by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA04421;
	Tue, 22 Sep 1998 17:39:26 -0400 (EDT)
	(envelope-from luoqi)
Date: Tue, 22 Sep 1998 17:39:26 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <199809222139.RAA04421@lor.watermarkgroup.com>
To: Don.Lewis@tsc.tdk.com, current@FreeBSD.ORG, luoqi@watermarkgroup.com
Subject: Re: Yet another patch to try for softupdates panic
Cc: mckusick@flamingo.McKusick.COM
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > You could tweak this call to VOP_FSYNC() to get it to avoid  the
> > call to softdep_fsync(), but how many other places in the kernel
> > also need to be fixed?  It may be better to only call softdep_fsync()
> > from within the fsync() syscall handler.  I don't know that any other
> > users of VOP_FSYNC() need to ensure that the parent directories are
> > pushed to disk.
> > 
> I totally agree. This is the way to go. I'll try this and let you know
> how it turns out.
> 
> -lq
> 
I have checked all places that VOP_FSYNC() is called, and I found that we
may not need the function softdep_fsync() after all.

Calls to VOP_FSYNC() can be basically grouped into 4 categories:
1. via the VFS_SYNC() call.
	In this case we don't need to call softdep_fsync(), because
	VOP_FSYNC() will be called for the parent directory too, and
	that should take care of the dependencies softdep_fsync() is
	supposed to get rid of.
2. via fsync() syscall and sync_fsync() by syncer.
	VOP_FSYNC() is called with MNT_LAZY and softdep_fsync() will not
	get called.
3. called for block device to flush disk buffers.
	softdep_fsync() will do nothing here
4. via vinvalbuf() and ffs_truncate()
	softdep_fsync() will introduce a race condition and we want to
	avoid it.

So the only case that softdep_fsync() actually does something useful is
exactly the case that we don't want softdep_fsync() to be called. Did I
miss anything here? I'm surprise myself at this conclusion. I will try
without softdep_fsync() and hope I won't trash my disk completely.

-lq

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message