From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 04:16:03 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A89C16A4BF for ; Mon, 8 Sep 2003 04:16:03 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8DB343FEC for ; Mon, 8 Sep 2003 04:16:01 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id VAA27748; Mon, 8 Sep 2003 21:15:40 +1000 Date: Mon, 8 Sep 2003 21:15:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John-Mark Gurney In-Reply-To: <20030907093323.GA780@libertysurf.fr> Message-ID: <20030908203814.L4621@gamplex.bde.org> References: <20030907093323.GA780@libertysurf.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: usb flashkey disk copy error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2003 11:16:03 -0000 On Sun, 7 Sep 2003, raoul.megelas wrote: > John-Mark Gurne wrote this message on Sun, Sep 07, 2003 at 08:45 +0200: > raoul.megelas wrote: > > > I have a copy error between hdd and a flashkey 1gig usb (easydisk) > > on Current dated August 28. Here is in short: > > > > mount -t msdos /dev/da2s1 /flashkey > > cp myfile /flashkey/ > > diff myfile /flashkey/myfile > > (ok). > > > could you try a fsync /flashkey/myfile before the umount? > > ... > > You have found the trick, fsync after cp works fine. > Thanks very much. > > But why the fsync is not automatically done by umount on umass? msdosfs_unmount() seems to be missing a VOP_FSYNC() of the vnode for the device file. This is needed to flush dirty metadata, if any. msdosfs_sync() is not missing this VOP_FSYNC(), and according to my debugging code it occasionally does something (unlike for ffs_sync() where there is almost always some dirty metadata. Perhaps there is another bug for VOP_CLOSE() on the device file to not do the sync, but ffs_unmount() does the VOP_FSYNC() explicitly (via ffs_flushfiles()). This may be just to get better error handling. In fact, there is another bug in ffs's not ignoring errors returned by VOP_CLOSE(): they cause null pointer panics if VOP_CLOSE() actually returns an error. Quick fix for ffs_unmount(): %%% Index: ffs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.216 diff -u -r1.216 ffs_vfsops.c --- ffs_vfsops.c 15 Aug 2003 20:03:19 -0000 1.216 +++ ffs_vfsops.c 17 Aug 2003 09:24:11 -0000 @@ -993,6 +998,12 @@ error = VOP_CLOSE(ump->um_devvp, FREAD|FWRITE, NOCRED, td); #endif + /* + * XXX don't fail if VOP_CLOSE() failed since we have destroyed + * our mount point and will soon destroy other resources. + */ + error = 0; + vrele(ump->um_devvp); free(fs->fs_csp, M_UFSMNT); %%% To see this bug, arrange for a disk driver to return nonzero from its close routine. Calling vflush() and VOP_FSYNC() before committing to finishing the unmount should result in there being no dirty blocks for VOP_CLOSE() to flush, so the correct error handling for failure of VOP_CLOSE() in the above may be to panic. Bruce