On Fri, Jun 21, 2019 at 4:50 PM Warner Losh <i...@bsdimp.com> wrote: > > > > On Fri, Jun 21, 2019, 3:44 PM Scott Long <sco...@samsco.org> wrote: >> >> >> >> > On Jun 21, 2019, at 4:37 PM, Warner Losh <i...@bsdimp.com> wrote: >> > >> > On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer <c...@freebsd.org> wrote: >> > >> >> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers <asom...@freebsd.org> wrote: >> >>> I would've thought that immediately following a sync(8), the >> >>> filesystem would be consistent. Why do I still see errors after a >> >>> panic in files that were written before I sync()ed? >> >>> -Alan >> >> >> >> Hi Alan, >> >> >> >> Contra the name, sync(2) (sync(8)) isn't synchronous. It invokes >> >> VFS_SYNC() with MNT_NOWAIT across all mountpoints. >> >> >> > >> > Yes. Sync(2) just starts the I/O, but it may be delayed if there is a lot >> > of dirty buffers. The other issue is that new buffers may be dirtied… >> > >> >> Still, the point of SU and SU+J is that the filesystem should not be >> damaged and require active repair on reboot, whether or not a >> sync or fsync was done. There’s certainly issues with disk lying >> about out of order writes, POSIX sematics of unlinked files, and the >> inherent design of UFS superblock updates, but the problems that >> Alan reported should still be looked at, they’re not expected and >> they undermine the usefulness of SU+J. > > > Yea. Ata write cache might cause it. But only once in a while and usually > only with power fail. Some drives / devices need a final flush, so that might > be an issue. I fixed an issue in nvme on shutdown like this, but panic should > trigger that code... > > Warner
No ATA write cache here. I'm using bhyve with a virtio disk. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
