From: Warner Losh <imp@bsdimp.com>
Date: Mon, 7 Aug 2017 23:56:36 -0600
Subject: Re: [Differential] D11589: Print more info when super blocks don't match, implement ability to ignore mismatches.
To: Kirk McKusick <mckusick@mckusick.com>
Cc: Warner Losh <imp@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, Scott Long <scottl@netflix.com>

Every UFS filesystem has a chunk of space reserved at the front for a boot block. Historically 8K, later 64K, now 256K. This size is known, so if we put a structure at the end of it with the BPG size, then fsck can find it and with great reliability find alternative superblocks. If the boot block is *entirely* filled, then we will lose that info, but it almost never is completely filled. As kib points out, administrators are running fsck when they are trying to fix their filesystems. It is far easier if fsck just deals with the problem rather than sending them off on some wild goose chase with other utilities to find alternate superblocks. Especially because this is a rare situation, but nearly always critical when it happens. We should not be lazy here. We should fix this issue.

Date: Sat, 22 Jul 2017 10:25:09 +0000
To: mckusick@freebsd.org
From: "kib (Konstantin Belousov)" <phabric-noreply@FreeBSD.org>
Subject: [Differential] D11589: Print more info when super blocks don't match, implement ability to ignore mismatches.

kib added a comment.

In https://reviews.freebsd.org/D11589#242174, @mckusick wrote:

Being able to search for alternate superblocks can be very
helpful. As discussed by Warner and myself in the email thread
below, to do so we need to be able to store a single 32-bit number
somewhere external to the filesystem. I really hope that someone
on this thread has an idea on where it could be placed.

If you can find a way to store BPG, I'll volunteer to figure
out how to get calcsb to use it.

Kirk, thank you very much. This (indirectly) answers the question
that I cannot answer myself and which blocked my understanding of
the patch. Am I right in the following statements:

If newfs was used with default settings, and the partition was not
resized, then alternate superblocks can be found by fsck using the
same calculation as was done by newfs.

Being able to search for alternate superblocks can be very helpful. As discussed by Warner and myself in the email thread below, to do so we need to be able to store a single 32-bit number somewhere external to the filesystem. I really hope that someone on this thread has an idea on where it could be placed.

This seems like a reasonable change. Definitely in keeping with the spirit of -y.

Looks good. Make it so.

With suggested change, I am happy with this (useful) update.

This change is a nice piece of work. Thanks for figuring it out. Going through your discussion with kib on the subtleties of the flags and hold count semantics makes me wish that it was simpler, but I do not see a way to do so and still be able to have the (very useful) semantics of vgone().

I like this solution much better than D10578.

This looks good to me.

I concur with imp's analysis. Once ENXIO is returned no more I/O will be possible, so the disk will remain in whatever state it is in. So it is always safe to just call softdep_disk_write_complete(bp); to clean up the dependencies and free their storage. There is still the issue that clearing some dependencies will allow others to proceed and those other may try to read data from the disk (such as the update of an inode). Almost always the update will be for something that is already cached, but occationally there will be a cache miss and so to ensure success we will need to augment soft updates to handle those cases. This is probably best done by setting a state flag (MNT_DISKGONE?) that indicates that the disk is gone and we are shutting down. In the (rather few) places in the soft depedencies code that we do reads, we check for that flag and provide a usable default which in most cases will just be a zeroed out buffer.

Here is a change that will at least clean up the soft updates associated with the buffer, though as noted if the filesystem keeps running it will put itself into an inconsistent and possibly unrecoverable state. This is no worse than what would happen with a filesystem running without soft updates if you continue operating after failing to do the I/O.

Additional changes are sensible and do not change functionality.

This looks like a useful change and should have no effect on functionality.

I did some sleuthing through BSDI sources and the addition of the MNT_LAZY flag check was put into getfsstat by one of the BSDI engineers apparently in response to a customer request. From there it got carried over to FreeBSD when I made the diffs for Julian who did the import.

I have nothing to add beyond the comments made by kib.

Make it so.

Thanks for the additions.Looks good to go.

Given the comparable performance measures by pho@ and mjg@, I suggest that this change be enabled by default.

I concur with the changes suggested by alc@

This looks good.

I am in agreement with the latest proposed change and am ready to have it committed.

I think that allowing the setting of creation time for ZFS is a sensible addition. Files coming off of archive media have good reason to set it.

I am happy that Garrett is spending some time measuring filesystem
performance. It has not been studied in some time, and it appears
that performance has dropped off since it peaked in FreeBSD 7 or 8.

All looks good and ready to commit.