Kirk McKusick 068beacf21 The goal of this change is to prevent accidental foot shooting by ... folks running filesystems created on check-hash enabled kernels (which I will call "new") on a non-check-hash enabled kernels (which I will call "old). The idea here is to detect when a filesystem is run on an old kernel and flag the filesystem so that when it gets moved back to a new kernel, it will not start getting a slew of check-hash errors. Back when the UFS version 2 filesystem was created, it added a file flag FS_INDEXDIRS that was to be set on any filesystem that kept some sort of on-disk indexing for directories. The idea was precisely to solve the issue we have today. Specifically that a newer kernel that supported indexing would be able to tell that the filesystem had been run on an older non-indexing kernel and that the indexes should not be used until they had been rebuilt. Since we have never implemented on-disk directory indicies, the FS_INDEXDIRS flag is cleared every time any UFS version 2 filesystem ever created is mounted for writing. This commit repurposes the FS_INDEXDIRS flag as the FS_METACKHASH flag. Thus, the FS_METACKHASH is definitively known to have always been cleared. The FS_INDEXDIRS flag has been moved to a new block of flags that will always be cleared starting with this commit (until they get used to implement some future feature which needs to detect that the filesystem was mounted on a kernel that predates the new feature). If a filesystem with check-hashes enabled is mounted on an old kernel the FS_METACKHASH flag is cleared. When that filesystem is mounted on a new kernel it will see that the FS_METACKHASH has been cleared and clears all of the fs_metackhash flags. To get them re-enabled the user must run fsck (in interactive mode without the -y flag) which will ask for each supported check hash whether it should be rebuilt and enabled. When fsck is run in its default preen mode, it will just ignore the check hashes so they will remain disabled. The kernel has always disabled any check hash functions that it does not support, so as more types of check hashes are added, we will get a non-surprising result. Specifically if filesystems get moved to kernels supporting fewer of the check hashes, those that are not supported will be disabled. If the filesystem is moved back to a kernel with more of the check-hashes available and fsck is run interactively to rebuild them, then their checking will resume. Otherwise just the smaller subset will be checked. A side effect of this commit is that filesystems running with cylinder-group check hashes will stop having them checked until fsck is run to re-enable them (since none of them currently have the FS_METACKHASH flag set). So, if you want check hashes enabled on your filesystems after booting a kernel with these changes, you need to run fsck to enable them. Any newly created filesystems will have check hashes enabled. If in doubt as to whether you have check hashes emabled, run dumpfs and look at the list of enabled flags at the end of the superblock details.		2018-02-08 23:06:58 +00:00
..
dumpfs.8	Renumber copyright clause 4	2017-02-28 23:42:47 +00:00
dumpfs.c	The goal of this change is to prevent accidental foot shooting by	2018-02-08 23:06:58 +00:00
Makefile
Makefile.depend	DIRDEPS_BUILD: Update dependencies.	2017-10-31 00:07:04 +00:00