Date: Fri, 3 May 2013 11:55:47 -0400 From: John Baldwin <jhb@freebsd.org> To: Konstantin Belousov <kib@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r250193 - head/sys/fs/msdosfs Message-ID: <201305031155.47559.jhb@freebsd.org> In-Reply-To: <201305022000.r42K0Bdk098965@svn.freebsd.org> References: <201305022000.r42K0Bdk098965@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305031155.47559.jhb>