From owner-svn-src-head@FreeBSD.ORG Fri May 3 17:20:19 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 813C7493; Fri, 3 May 2013 17:20:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5F99C12D1; Fri, 3 May 2013 17:20:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ACE7AB990; Fri, 3 May 2013 13:20:18 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: svn commit: r250193 - head/sys/fs/msdosfs Date: Fri, 3 May 2013 11:55:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305022000.r42K0Bdk098965@svn.freebsd.org> In-Reply-To: <201305022000.r42K0Bdk098965@svn.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201305031155.47559.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 May 2013 13:20:18 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:20:19 -0000 On Thursday, May 02, 2013 4:00:11 pm Konstantin Belousov wrote: > Author: kib > Date: Thu May 2 20:00:11 2013 > New Revision: 250193 > URL: http://svnweb.freebsd.org/changeset/base/250193 > > Log: > The fsync(2) call should sync the vnode in such way that even after > system crash which happen after successfull fsync() return, the data > is accessible. For msdosfs, this means that FAT entries for the file > must be written. > > Since we do not track the FAT blocks containing entries for the > current file, just do a sloppy sync of the devvp vnode for the mount, > which buffers, among other things, contain FAT blocks. > > Simultaneously, for deupdat(): > - optimize by clearing the modified flags before short-circuiting a > return, if the mount is read-only; > - only ignore the rest of the function for denode with DE_MODIFIED > flag clear when the waitfor argument is false. The directory buffer > for the entry might be of delayed write; > - microoptimize by comparing the updated directory entry with the > current block content; > - try to cluster the write, fall back to bawrite() if low on > resources. > > Based on the submission by: bde > MFC after: 2 weeks Does this fix kern/62762? -- John Baldwin