Rev 244218 removed the requirement that you provide a dump
directory when checking if there is a coredump ready to be written.
That had the side-effect of causing the bounds file to be read
from the current working directory instead of the dump directory.
As the bounds file is irrelevant when just checking, the simplest
fix is to not read the bounds file when checking.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14383
select(2) should be declared as restrict. In addition the only fd in
the fdset is open O_RDONLY, and it's not a socket that can provide OOB
notifications,
Reviewed by: ian, imp, vangyzen
This works similarly to the existing gzip compression support, but
zstd is typically faster and gives better compression ratios.
Support for this functionality must be configured by adding ZSTDIO to
one's kernel configuration file. dumpon(8)'s new -Z option is used to
configure zstd compression for kernel dumps. savecore(8) now recognizes
and saves zstd-compressed kernel dumps with a .zst extension.
Submitted by: cem (original version)
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13101,
https://reviews.freebsd.org/D13633
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.
Most consumers of g_metadata_store were passing in partially unallocated
memory, resulting in stack garbage being written to disk labels. Fix them by
zeroing the memory first.
gvirstor repeated the same mistake, but in the kernel.
Also, glabel's label contained a fixed-size string that wasn't
initialized to zero.
PR: 222077
Reported by: Maxim Khitrov <max@mxcrypt.com>
Reviewed by: cem
MFC after: 3 weeks
X-MFC-With: 323314
X-MFC-With: 323338
Differential Revision: https://reviews.freebsd.org/D14164
Specifically reading is done if ffs_sbget() and writing is done
in ffs_sbput(). These functions are exported to libufs via the
sbget() and sbput() functions which then used in the various
filesystem utilities. This work is in preparation for adding
subperblock check hashes.
No functional change intended.
Reviewed by: kib
routine to write out the cylinder groups rather than recreating the
calculation of the cylinder-group check hash in fsck_ffs.
No functional change intended.
Make it possible to retrieve mmc parameters via the XPT_GET_ADVINFO
call instead. Convert camcontrol to the new scheme.
Reviewed by: imp. kibab
Sponsored by: Netflix
Differential Revision: D13868
check-hash after making changes to the cylinder group. The problem
was that the journal-recovery code was calling the libufs bwrite()
function instead of the cgput() function. The cgput() function updates
the cylinder-group check-hash before writing the cylinder group.
This change required the additions of the cgget() and cgput() functions
to the libufs API to avoid a gratuitous bcopy of every cylinder group
to be read or written. These new functions have been added to the
libufs manual pages. This was the first opportunity that I have had
to use and document the use of the EDOOFUS error code.
Reviewed by: kib
Reported by: emaste and others
When the fsck_ffs program cannot fully repair a file system, it will
output the message PLEASE RERUN FSCK. However, it does not exit with a
non-zero status in this case (contradicting the man page claim that it
"exits with 0 on success, and >0 if an error occurs." The fsck
rc-script (when running "fsck -y") tests the status from fsck (which
passes along the exit status from fsck_ffs) and issues a "stop_boot"
if the status fails. However, this is not effective since fsck_ffs can
return zero even on (some) errors. Effectively, it is left to a later
step in the boot process when the file systems are mounted to detect
the still-unclean file system and stop the boot.
This change modifies fsck_ffs so that when it cannot fully repair the
file system and issues the PLEASE RERUN FSCK message it also exits
with a non-zero status.
While here, the fsck_ffs man page has also been updated to document
the failing exit status codes used by fsck_ffs. Previously, only exit
status 7 was documented. Some of these exit statuses are tested for in
the fsck rc-script, so they are clearly depended upon and deserve
documentation.
Reviewed by: mckusick, vangyzen, jilles (manpages)
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D13862
previous behavior is preserved (the CG checksum is fixed). We're just
noisy about it now.
Reviewed by: kirk@
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13884
The previous language did not make it clear that 'Files' are
the files specified above. Clarify it.
Reported by: dana <dana@dana.is>
Reviewed by: dana <dana@dana.is>
MFC After: 1 week
The original bug describes it best:
When an absolute time is specified to shutdown, the program's
behavior depends on whether that time has passed during the
current calendar day. POLA would suggest that for shutdown,
whose time argument is always supposed to be in the future,
absolute times specified without a specific date should refer
to the next occurrence of that time, rather than erroring out
if that time has already passed during the current day.
PR: 32411
Submitted by: wollman@khavrinen.lcs.mit.edu
Submitted on: 2001-11-30 20:30:01 UTC
Reviewed by: asmodai (at time of bug submission)
The code originated in NetBSD which has since removed Clauses 3 and 4.
Approved by: phk (concerning his own copyright)
Obtained from: NetBSD (CVS ccdconfig.c 1.47, ccdconfig.8 1.24)
The code originate in NetBSD and there are the copyright notes have been
assigned to the NetBSD Foundation. Update the files up to the point where
we started diverging.
Further relaxation of the licensing terms are possible after we
check the NetBSD updates, and contact the local authors.
In the case of ccdconfig.8 this reinstates the 3rd clause but since the
code is not directly from Berkeley, the change was bogus.
Obtained from: NetBSD
