- User Since
- Oct 24 2014, 7:17 PM (146 w, 6 d)
Wed, Aug 16
Mon, Aug 14
Sun, Aug 13
Wed, Aug 9
From: Warner Losh <firstname.lastname@example.org>
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 <email@example.com>
Cc: Warner Losh <firstname.lastname@example.org>, Konstantin Belousov <email@example.com>, Scott Long <firstname.lastname@example.org>
Mon, Aug 7
Tue, Aug 1
Mon, Jul 31
Mon, Jul 24
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.
Sat, Jul 22
Date: Sat, 22 Jul 2017 10:25:09 +0000
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.
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.
Fri, Jul 21
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.
Jul 10 2017
This seems like a reasonable change. Definitely in keeping with the spirit of -y.
Jun 28 2017
Jun 26 2017
Jun 20 2017
May 23 2017
Looks good. Make it so.
May 22 2017
With suggested change, I am happy with this (useful) update.
May 13 2017
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().
May 4 2017
I like this solution much better than D10578.
Apr 12 2017
Feb 21 2017
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.
Feb 15 2017
Additional changes are sensible and do not change functionality.
This looks like a useful change and should have no effect on functionality.
Jan 22 2017
Dec 22 2016
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.
Nov 26 2016
Nov 22 2016
Nov 16 2016
Nov 12 2016
I have nothing to add beyond the comments made by kib.
Oct 28 2016
Oct 26 2016
Oct 17 2016
Oct 16 2016
Thanks for the additions.Looks good to go.
Oct 15 2016
Given the comparable performance measures by pho@ and mjg@, I suggest that this change be enabled by default.
Oct 14 2016
I concur with the changes suggested by alc@
Oct 13 2016
Aug 19 2016
Aug 16 2016
Aug 15 2016
I am in agreement with the latest proposed change and am ready to have it committed.
Feb 24 2016
Feb 7 2016
Jan 27 2016
Jan 21 2016
Dec 30 2015
Dec 4 2015
Dec 3 2015
Nov 30 2015
Oct 27 2015
Oct 23 2015
Sep 22 2015
Sep 6 2015
Jul 19 2015
May 28 2015
May 18 2015
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.
Apr 24 2015
Apr 13 2015
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.