Re: Reducing UFS corruption from unclean shutdowns?

From: Alan Somers <asomers_at_freebsd.org>
Date: Fri, 21 Jun 2019 16:51:44 -0600
On Fri, Jun 21, 2019 at 4:50 PM Warner Losh <imp_at_bsdimp.com> wrote:
>
>
>
> 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

No ATA write cache here.  I'm using bhyve with a virtio disk.
Received on Fri Jun 21 2019 - 20:52:04 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC