- User Since
- Oct 24 2014, 7:17 PM (173 w, 6 d)
Wed, Feb 21
Fri, Feb 9
Thu, Feb 8
In response to brooks. You are correct that this always allocates one block and initialises it to zero. Thus all zero-length directories will sort to the front of the list so that they will all be reported in a block.
Wed, Feb 7
Tue, Feb 6
Fri, Feb 2
I agree with the problem, but propose this new diff as the correct solution.
I concur with the problem, but differ on the solution. When I tried to upload my proposed change it created a whole new report https://reviews.freebsd.org/D14177. How do I just attach a new diff here?
Wed, Jan 31
Mon, Jan 29
I agree that the dependency needs to be added though I am not sure precisely how it should be done. I suggest added kib@ as a reviewer because he is up-to-date with the way that these sorts of dependencies should be indicated.
Fri, Jan 26
Thu, Jan 25
This is the correct fix.
Wed, Jan 24
Jan 23 2018
Jan 17 2018
Jan 14 2018
Approve of latest change.
Jan 13 2018
This looks like a sensible and long overdue change.
Given the issues that have been raised by adding the checkhash, I am thinking that it may be better not to enable it by default. If it is (for now) only enabled optionally, then folks that want to test it can do so and the rest of the users do not have to deal with the testing shake-out. I want to add other checkhashes for things like superblocks, inodes and possibly indirect blocks. Once these are working as a whole, then we can expand them to the larger population. In particular, I want to add the ability to detect when a filesystem is run on an earlier kernel so that we will expect the checkhashes to be wrong. I have just one bit to work with here, so I want to defer adding this until I can use it to cover all the checkhashes. But I think that this ability to detect running on earlier kernels is important to have for the wider population of users.
Using pfatal means that fsck -p (preen mode) will fail causing a reboot to drop into single user mode with a request that you run fsck manually. If you use pwarn, then a message will be generated but the system will continue to multi-user. I believe that pwarn is more appropriate in this case since you are not in danger of corrupting your filesystem when the checksum is wrong.
Dec 27 2017
Dec 26 2017
Dec 9 2017
I believe that the correct solution is to make barrier writes work correctly as they can be used to solve a multitude of problems. Indeed I would use them more extensively in UFS if I believed that they worked. That said, I suggest a comment over the definition of the doasyncinodeinit that explains that synchronous inode initialization is only needed when barrier writes do not work.
Dec 6 2017
This looks like an excellent improvement. I have not reviewed every line of code, but the concept is sound.
Oct 31 2017
Oct 17 2017
Oct 16 2017
Oct 10 2017
Oct 9 2017
Sep 22 2017
Sep 4 2017
Aug 24 2017
Aug 23 2017
Aug 22 2017
Aug 16 2017
Aug 14 2017
Aug 13 2017
Aug 9 2017
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>
Aug 7 2017
Aug 1 2017
Jul 31 2017
Jul 24 2017
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.
Jul 22 2017
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.
Jul 21 2017
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.