On Fri, Jun 21, 2019, 3:44 PM Scott Long <scottl_at_samsco.org> wrote: > > > > On Jun 21, 2019, at 4:37 PM, Warner Losh <imp_at_bsdimp.com> wrote: > > > > On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer <cem_at_freebsd.org> wrote: > > > >> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers <asomers_at_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 Scott > > > >Received on Fri Jun 21 2019 - 20:50:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC