Date: Fri, 21 Jun 2019 16:51:44 -0600 From: Alan Somers <asomers@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Scott Long <scottl@samsco.org>, "Conrad E. Meyer" <cem@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Reducing UFS corruption from unclean shutdowns? Message-ID: <CAOtMX2ikkZrekiR9QC91tAP-UuxnfjpkBSf_9i-mKgxj9rMgRA@mail.gmail.com> In-Reply-To: <CANCZdfriNeWKch0pz87vR9wXniTDUx9vSjX1WX6%2BVmj4FiU4NQ@mail.gmail.com> References: <CAOtMX2jPut4ve-Tr7DyikxXqnmqycyjEUpNmAiwUSXbQrK3iCA@mail.gmail.com> <C3016BDF-4B51-4A59-94F2-CCBD0DC4562E@samsco.org> <CAOtMX2jXiaOWpVdEg3_nBYinJWd=iwN_38hQ4eMOocgs8dMWhQ@mail.gmail.com> <F93827F6-1B99-4BDD-B245-C9594AD28ED7@samsco.org> <tkrat.bc0479d0867a8175@FreeBSD.org> <D7FC707D-B863-47F2-9580-C07881AAC866@samsco.org> <CAOtMX2heRbFONA4e7-buFgZeykCW13h1dC1DTVYOLFAier8wPg@mail.gmail.com> <CAG6CVpVZ2YaWzc7YbAoP=sY_NK4qcDbkyctDBW%2BOXoY6Du3WYQ@mail.gmail.com> <CANCZdfoEkRWqswsYj74STRByec41J5SWdvK%2BKcRqe5KJS6YV8w@mail.gmail.com> <17B3F210-5101-449F-AE06-326F890C3C01@samsco.org> <CANCZdfriNeWKch0pz87vR9wXniTDUx9vSjX1WX6%2BVmj4FiU4NQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 21, 2019 at 4:50 PM Warner Losh <imp@bsdimp.com> wrote: > > > > On Fri, Jun 21, 2019, 3:44 PM Scott Long <scottl@samsco.org> wrote: >> >> >> >> > On Jun 21, 2019, at 4:37 PM, Warner Losh <imp@bsdimp.com> wrote: >> > >> > On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer <cem@freebsd.org> wrote: >> > >> >> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers <asomers@freebsd.org> wro= te: >> >>> 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= =E2=80=A6 >> > >> >> 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=E2=80=99s certainly issues with disk lyin= g >> 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=E2=80=99re not expected an= d >> 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 mi= ght 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2ikkZrekiR9QC91tAP-UuxnfjpkBSf_9i-mKgxj9rMgRA>