#
0b8224d1 |
| 24-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove copyright strings ifdef'd out
We've ifdef'd out the copyright strings for some time now. Go ahead and remove the ifdefs. Plus whatever other detritis was left over from other recent removals.
Remove copyright strings ifdef'd out
We've ifdef'd out the copyright strings for some time now. Go ahead and remove the ifdefs. Plus whatever other detritis was left over from other recent removals. These copyright strings are present in the comments and are largely from CSRG's attempt at adding their copyright to every binary file (which modern interpretations of the license doesn't require).
Sponsored by: Netflix
show more ...
|
#
51e16cb8 |
| 23-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sbin: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl
sbin: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl script.
Sponsored by: Netflix
show more ...
|
#
772430dd |
| 17-Nov-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Ensure I/O buffers in libufs(3) are 128-byte aligned.
Various disk controllers require their buffers to be aligned to a cache-line size (128 bytes). For buffers allocated in structures, ensure that
Ensure I/O buffers in libufs(3) are 128-byte aligned.
Various disk controllers require their buffers to be aligned to a cache-line size (128 bytes). For buffers allocated in structures, ensure that they are 128-byte aligned. Use aligned_malloc to allocate memory to ensure that the returned memory is 128-byte aligned.
While we are here, we replace the dynamically allocated inode buffer with a buffer allocated in the uufsd structure just as the superblock and cylinder group buffers do.
This can be removed if/when the kernel is fixed. Because this problem has existed on one I/O subsystem or another since the 1990's, we are probably stuck with dealing with it forever.
The problem most recent showed up in Azure, see: https://reviews.freebsd.org/D41728 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267654 Before these fixes were applied, it was confirmed that the changes in this commit also fixed the issue in Azure.
Reviewed-by: Warner Losh, kib Tested-by: Souradeep Chakrabarti of Microsoft (earlier version) PR: 267654 Differential Revision: https://reviews.freebsd.org/D41724
show more ...
|
Revision tags: release/14.0.0 |
|
#
d3a36e4b |
| 26-Oct-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Delete snapshot after opening it when running fsck_ffs(9) in background.
When fsck_ffs(8) runs in background, it creates a snapshot named fsck_snapshot in the filesystem's .snap directory. The fsck_
Delete snapshot after opening it when running fsck_ffs(9) in background.
When fsck_ffs(8) runs in background, it creates a snapshot named fsck_snapshot in the filesystem's .snap directory. The fsck_snapshot file was removed when the background fsck finished. If the system crashed or the fsck exited unexpectedly, the fsck_snapshot file would remain. The snapshot would consume ever more space as the filesystem changed over time until it was removed by a system administrator or a future run of background fsck removed it to create a new snapshot file.
This commit unlinks the .snap/fsck_snapshot file immediately after opening it so that it will be reclaimed when fsck closes it at the conclusion of its run. After a system crash, it will be removed as part of the filesystem cleanup because of its zero reference count. As only a few milliseconds pass between its creation and unlinking, there is far less opportunity for it to be accidentally left behind.
PR: 106107 MFC-after: 1 week
show more ...
|
#
1d386b48 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
344b5bf8 |
| 01-Aug-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Support background fsck_ffs(8) on filesystems using journaled soft updates
An earlier addition of code to fsck_ffs(8) allowed it to support snapshots when running with journalled soft updates. Furth
Support background fsck_ffs(8) on filesystems using journaled soft updates
An earlier addition of code to fsck_ffs(8) allowed it to support snapshots when running with journalled soft updates. Further functionality has now been added to fsck_ffs(8) to allow it to use snapshots to run in background on live filesystems running with journaled soft updates. This commit enables the use of this functionality.
Tested-by: Peter Holm Sponsored-by: The FreeBSD Foundation MFC-after: 2 weeks
show more ...
|
#
4d512b07 |
| 25-Jul-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Debugging output additions. No functional changes intended.
MFC-after: 1 week Sponsored-by: The FreeBSD Foundation
|
#
239597e0 |
| 18-Jul-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Text format cleanups. No functional changes intended.
MFC-after: 1 week Sponsored-by: The FreeBSD Foundation
|
#
4b08a62e |
| 26-May-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
When running fsck_ffs(8) in background ensure that a superblock has been read.
Reported by: Mikhail T. PR: 271352 MFC after: 1 week Sponsored by: The FreeBSD Foundation
|
#
40647558 |
| 03-May-2023 |
Chuck Silvers <chs@FreeBSD.org> |
fsck_ffs: fix the previous change that skipped pass 5 in some cases
The previous change involved calling check_cgmagic() twice in a row for the same CG in order to differentiate when the CG was alre
fsck_ffs: fix the previous change that skipped pass 5 in some cases
The previous change involved calling check_cgmagic() twice in a row for the same CG in order to differentiate when the CG was already ok vs. when the CG was rebuilt, but that doesn't work because the second call (which was supposed to rebuild the CG) returns 0 (indicating that the CG was not rebuilt) due to the prevfailcg check causing an early failure return. Fix this by moving the rebuild part of check_cgmagic() out into a separate function which is called by pass1() when it wants to rebuild a CG.
Fixes: da86e7a20dc4a4b17e8d9e7630ed9b675cf71702 Reported by: pho Discussed with: mckusick Sponsored by: Netflix
show more ...
|
#
da86e7a2 |
| 19-Apr-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Skip Pass 5 in fsck_ffs(8) when corrupt cylinder groups remain unfixed.
Pass 1 of fsck_ffs checks the integrity of all the cylinder groups. If any are found to have been corrupted it offers to rebui
Skip Pass 5 in fsck_ffs(8) when corrupt cylinder groups remain unfixed.
Pass 1 of fsck_ffs checks the integrity of all the cylinder groups. If any are found to have been corrupted it offers to rebuild them. Pass 5 then makes a second pass over the cylinder groups to validate their block and inode maps. Pass 5 assumes that the cylinder groups are not corrupted and can segment fault if they are corrupted. Rather than rerunning the corruption checks a second time in pass 5, this fix keeps track whether any corrupt cylinder groups were found but not fixed in pass 1 either due to running with the -n flag or by explicitly answering `no' when asked whether to fix a corrupted cylinder group. If any corrupted cylinder groups remain after pass 1, fsck_ffs will decline to run pass 5. Instead it marks the filesystem as unclean so that fsck_ffs will need to be run again before the filesystem can be mounted.
This patch cleans up and documents the return value from check_cgmagic(). It also renames the variable / parameter "rebuildcg" to "rebuiltcg". This parameter describes whether the cylinder group has been rebuilt rather than whether it should be rebuilt.
Reported by: Chuck Silvers Reviewed by: Chuck Silvers MFC after: 1 week
show more ...
|
Revision tags: release/13.2.0 |
|
#
5942b4b6 |
| 14-Feb-2023 |
Konstantin Belousov <kib@FreeBSD.org> |
sys/param.h: Add _WANT_P_OSREL
Use it instead of defining IN_RTLD by base sources that want P_OSREL_ defines in userspace, but are not rtld. This allows to remove abuse of IN_RTLD from userspace.
R
sys/param.h: Add _WANT_P_OSREL
Use it instead of defining IN_RTLD by base sources that want P_OSREL_ defines in userspace, but are not rtld. This allows to remove abuse of IN_RTLD from userspace.
Reviewed by: dchagin, markj, imp Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D38585
show more ...
|
#
906c312b |
| 15-Jan-2023 |
Kirk McKusick <mckusick@FreeBSD.org> |
Document the mntopts(3) functions.
The mntopts(3) functions support operations associated with a mount point. The main purpose of this commit is to document the mntopts(3) functions that now appear
Document the mntopts(3) functions.
The mntopts(3) functions support operations associated with a mount point. The main purpose of this commit is to document the mntopts(3) functions that now appear in 18 utilities in the base system. See mntopts(3) for the documentation details.
The getmntopts() function appeared in 4.4BSD. The build_iovec(), build_iovec_argf(), free_iovec(), checkpath(), and rmslashes() functions were added with nmount(8) in FreeBSD 5.0. The getmntpoint() and chkdoreload() functions are being added in this commit.
These functions should be in a library but for historic reasons are in a file in the sources for the mount(8) program. Thus, to access them the following lines need to be added to the Makefile of the program wanting to use them:
SRCS+= getmntopts.c MOUNT= ${SRCTOP}/sbin/mount CFLAGS+= -I${MOUNT} .PATH: ${MOUNT}
Once these changes have been MFC'ed to 13 they may be made into a library.
Reviewed by: kib, gbe MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D37907
show more ...
|
Revision tags: release/12.4.0 |
|
#
460ed610 |
| 09-Nov-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Add support for managing UFS/FFS snapshots to fsck_ffs(8).
The kernel handles the managment of UFS/FFS snapshots. Since UFS/FFS updates filesystem data (rather than always writing changes to new loc
Add support for managing UFS/FFS snapshots to fsck_ffs(8).
The kernel handles the managment of UFS/FFS snapshots. Since UFS/FFS updates filesystem data (rather than always writing changes to new locations like ZFS), the kernel must check every filesystem write to see if the block being written is part of a snapshot. If it is part of a snapshot, then the kernel must make a copy of the old block value into a newly allocated block for the snapshot before allowing the write to be done. Similarly, if a block is being freed, the kernel must check to see if it is part of a snapshot and let the snapshot claim the block rather than freeing it for future use. When a snapshot is freed, its blocks need to be offered to older snapshots and freed only if no older snapshots wish to claim them.
When snapshots were added to UFS/FFS they were integrated into soft updates and just a small part of the management of snapshots needed to be added to fsck_ffs(8) as soft updates minimized the set of snapshot changes that might need correction. When journaling was added to soft updates a much more complete knowledge of snapshots needed to be added to fsck_ffs(8) for it to be able to properly handle the filesystem changes that a journal rollback needs to do (specifically the freeing and allocation of blocks). Since this functionality was unavailable, the use of snapshots was disabled when running with journaled soft updates.
This set of changes imports the kernel code for the management of snapshots to fsck_ffs(8). With this code in place it will become possible to enable snapshots when running with journalled soft updates. The most immediate benefit will be the ability to use snapshots to take consistent filesystem dumps on live filesystems. Future work will be done to update fsck_ffs(8) to be able to use snapshots to run in background on live filesystems running with journaled soft updates.
Reviewed by: kib Tested by: Peter Holm Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D36491
show more ...
|
#
e6886616 |
| 13-Aug-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Move the ability to search for alternate UFS superblocks from fsck_ffs(8) into ffs_sbsearch() to allow use by other parts of the system.
Historically only fsck_ffs(8), the UFS filesystem checker, ha
Move the ability to search for alternate UFS superblocks from fsck_ffs(8) into ffs_sbsearch() to allow use by other parts of the system.
Historically only fsck_ffs(8), the UFS filesystem checker, had code to track down and use alternate UFS superblocks. Since fsdb(8) used much of the fsck_ffs(8) implementation it had some ability to track down alternate superblocks.
This change extracts the code to track down alternate superblocks from fsck_ffs(8) and puts it into a new function ffs_sbsearch() in sys/ufs/ffs/ffs_subr.c. Like ffs_sbget() and ffs_sbput() also found in ffs_subr.c, these functions can be used directly by the kernel subsystems. Additionally they are exported to the UFS library, libufs(8) so that they can be used by user-level programs. The new functions added to libufs(8) are sbfind(3) that is an alternative to sbread(3) and sbsearch(3) that is an alternative to sbget(3). See their manual pages for further details.
The utilities that have been changed to search for superblocks are dumpfs(8), fsdb(8), ffsinfo(8), and fsck_ffs(8). Also, the prtblknos(8) tool found in tools/diag/prtblknos searches for superblocks.
The UFS specific mount code uses the superblock search interface when mounting the root filesystem and when the administrator doing a mount(8) command specifies the force flag (-f). The standalone UFS boot code (found in stand/libsa/ufs.c) uses the superblock search code in the hope of being able to get the system up and running so that fsck_ffs(8) can be used to get the filesystem cleaned up.
The following utilities have not been changed to search for superblocks: clri(8), tunefs(8), snapinfo(8), fstyp(8), quot(8), dump(8), fsirand(8), growfs(8), quotacheck(8), gjournal(8), and glabel(8). When these utilities fail, they do report the cause of the failure. The one exception is the tasting code used to try and figure what a given disk contains. The tasting code will remain silent so as not to put out a slew of messages as it trying to taste every new mass storage device that shows up.
Reviewed by: kib Reviewed by: Warner Losh Tested by: Peter Holm Differential Revision: https://reviews.freebsd.org/D36053 Sponsored by: The FreeBSD Foundation
show more ...
|
Revision tags: release/13.1.0 |
|
#
299fcf40 |
| 09-Apr-2022 |
Gordon Bergling <gbe@FreeBSD.org> |
fsck_ffs(8): Fix a typo in a source code comment
- s/it it/if it/
MFC after: 3 days
|
#
c5d476c9 |
| 24-Feb-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Update fsdb(8) to reflect new structure of fsck_ffs(8).
The cleanup of fsck_ffs(8) in commit c0bfa109b942659f6 broke fsdb(8). This commit adds the one-line update needed in fsdb(8) to make it work w
Update fsdb(8) to reflect new structure of fsck_ffs(8).
The cleanup of fsck_ffs(8) in commit c0bfa109b942659f6 broke fsdb(8). This commit adds the one-line update needed in fsdb(8) to make it work with the new fsck_ffs(8) structure.
Reported by: Chuck Silvers Tested by: Chuck Silvers MFC after: 3 days
show more ...
|
#
9583be04 |
| 04-Feb-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Properly fix parameter to sysctlnametomib().
|
#
504cb544 |
| 04-Feb-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Fix parameter to sysctlnametomib();
|
#
c0bfa109 |
| 04-Feb-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Have fsck_ffs(8) properly correct superblock check-hash failures.
Part of the problem was that fsck_ffs would read the superblock multiple times complaining and repairing the superblock check hash e
Have fsck_ffs(8) properly correct superblock check-hash failures.
Part of the problem was that fsck_ffs would read the superblock multiple times complaining and repairing the superblock check hash each time and then at the end failing to write out the superblock with the corrected check hash. This fix reads the superblock just once and if the check hash is corrected ensures that the fixed superblock gets written.
Tested by: Peter Holm PR: 245916 MFC after: 1 week Sponsored by: Netflix
show more ...
|
#
c82df0a0 |
| 06-Jan-2022 |
Kirk McKusick <mckusick@FreeBSD.org> |
Whitespace and capitalization cleanups.
No changes intended.
Sponsored by: Netflix
|
Revision tags: release/12.3.0 |
|
#
0c5a5925 |
| 11-Jul-2021 |
Robert Wing <rew@FreeBSD.org> |
fsck_ffs: fix background fsck in preen mode
Background checks are only allowed for mounted filesystems - don't try to open the device for writing when performing a background check.
While here, rem
fsck_ffs: fix background fsck in preen mode
Background checks are only allowed for mounted filesystems - don't try to open the device for writing when performing a background check.
While here, remove a debugging printf that's commented out.
PR: 256746 Fixes: 5cc52631b3b88dfc36d8049dc8bece8573c5f9af Reviewed by: mckusick MFC After: 1 week Differential Revision: https://reviews.freebsd.org/D30880
show more ...
|
#
ed1a156b |
| 29-Jun-2021 |
Chuck Silvers <chs@FreeBSD.org> |
fsck_ffs: don't try to write in read-only mode
Skip trying to change fs_mtime for SU+J if we are running read-only.
Reviewed by: mckusick Sponsored by: Netflix
|
#
441e69e4 |
| 03-Jun-2021 |
Robert Wing <rew@FreeBSD.org> |
fsck_ufs: fix segfault with gjournal
The segfault was being hit in ckfini() (sbin/fsck_ffs/fsutil.c) while attempting to traverse the buffer cache. The tail queue used for the buffer cache was not i
fsck_ufs: fix segfault with gjournal
The segfault was being hit in ckfini() (sbin/fsck_ffs/fsutil.c) while attempting to traverse the buffer cache. The tail queue used for the buffer cache was not initialized before dropping into gjournal_check().
Initialize the buffer cache before calling gjournal_check().
PR: 245907 Reviewed by: jhb, mckusick MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D30537
show more ...
|
#
9b0f1d64 |
| 29-May-2021 |
Robert Wing <rew@FreeBSD.org> |
Revert "Fix fsck_ufs segfaults with gjournal (SU+J)"
Fix fsck for 32-bit platforms.
This reverts commit f190f9193bc10a8193c87e0a02fa91400e4eb159.
|