Date: Fri, 17 Sep 1999 10:58:50 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Dan Nelson <dnelson@emsphone.com>, Brad Knowles <blk@skynet.be>, Thomas Dean <tomdean@ix.netcom.com>, freebsd-current@FreeBSD.ORG Subject: Re: More benchmarking stuff... Message-ID: <Pine.BSF.3.95.990917105603.747A-100000@current1.whistle.com> In-Reply-To: <199909171717.KAA53861@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Sep 1999, Matthew Dillon wrote: > :According to kirk FSYNC() does the right thing and 'sync()' doesn't. > : > > Lets see... well, it will sync the file state, but it will not > necessarily sync the related directory entry (as far as I can tell). > > So if you take a case such as sendmail creating a queue file, fsync > will succeed and the file itself will be consistent, but the directory > entry for the file may not yet have been created and synced. A crash > at that point would result in a missing file. > > Kirk would know for sure. According to kirk, the fsync() will not return until all meta data back to the root has been sync'd, (welllllllll, all "CONTIGUOUSLY TRACKED" metadata.... i.e unitll the chain hit's something already sync'd. ) > > - > > At some point we need to extend the kernel VOP_FSYNC API to include > a file offset/range so NFS can conditionally fsync part of a file and > know for sure that it's data and metadata have gone to the platter. > And its directory entry as well in the case of a newly created file. > > -Matt > Matthew Dillon > <dillon@backplane.com> > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990917105603.747A-100000>