Page MenuHomeFreeBSD

mckusick (Marshall Kirk McKusick)
User

Projects

User Details

User Since
Oct 24 2014, 7:17 PM (331 w, 4 d)

Recent Activity

Yesterday

mckusick added a comment to D28999: FFS extattr: fix handling of the tail.

Sorry for the delayed review. This change looks correct to me.

Tue, Mar 2, 5:55 PM
mckusick added a comment to D26999: Remove an extra if_ref()..

Sorry for the delayed review. This fix looks correct to me.

Tue, Mar 2, 5:54 PM

Thu, Feb 25

mckusick added a comment to D28901: buf: Fix the dirtybufthresh check.

It appears that this change should be MFC'ed to 12.

Thu, Feb 25, 12:24 AM

Wed, Feb 24

mckusick accepted D28901: buf: Fix the dirtybufthresh check.
Wed, Feb 24, 6:11 AM

Sat, Feb 20

mckusick accepted D28679: vnode: move write cluster support data to inodes..

Its a wrap!

Sat, Feb 20, 1:03 AM

Thu, Feb 18

mckusick added a comment to D28679: vnode: move write cluster support data to inodes..

I note that lib/libprocstat/libprocstat.c includes ufs/ufs/inode.h but in fact does not need to do so.

Thu, Feb 18, 10:53 PM
mckusick accepted D28679: vnode: move write cluster support data to inodes..

Getting rid of _buf_cluster.h was a lot more work than I expected, but is definitely cleaner and has the added bonus of cleaning up some other cruft as well.

Thu, Feb 18, 10:49 PM
mckusick accepted D28679: vnode: move write cluster support data to inodes..

The problem is in lib/libprocstat that wants to read inodes out of the kernel so needs to know their size. So, I agree avoiding _buf_cluster.h is hard. I reluctantly agree with that solution.

Thu, Feb 18, 6:31 AM

Wed, Feb 17

mckusick added a comment to D28679: vnode: move write cluster support data to inodes..

To avoid the _buf_cluster.h file, how about making the inclusion of buf.h in ufs/inode.h and ext2fs/inode.h conditional on #ifdef KERNEL? Both vfs_cluster.c and fuse_node.h already include buf.h so are not an issue. I don't know if msdosfs/denode.h is used outside the kernel, but if so could make inclusion of buf.h conditional on #ifdef KERNEL.

Wed, Feb 17, 8:32 PM
mckusick accepted D28697: lockf: ensure atomicity of lockf for open(O_CREAT|O_EXCL|O_EXLOCK).

All looks good.

Wed, Feb 17, 8:09 PM

Tue, Feb 16

mckusick added a comment to D28697: lockf: ensure atomicity of lockf for open(O_CREAT|O_EXCL|O_EXLOCK).

Overall looks good.

Tue, Feb 16, 9:58 PM
mckusick added a comment to D28679: vnode: move write cluster support data to inodes..

Overall looks good. A few inline comments.

Tue, Feb 16, 7:27 PM
mckusick accepted D28675: cache: add an introductory comment.

Thanks for rewriting this comment.
I have provided some suggestions for cleanup and/or clarification.

Tue, Feb 16, 1:23 AM

Fri, Feb 12

mckusick committed R10:8563de2f2799: Fix bug 253158 - Panic: snapacct_ufs2: bad block - mksnap_ffs(8) crash (authored by mckusick).
Fix bug 253158 - Panic: snapacct_ufs2: bad block - mksnap_ffs(8) crash
Fri, Feb 12, 5:36 AM

Jan 30 2021

mckusick committed R10:1f9ee757d96d: MFC: 8c22cf9b (authored by mckusick).
MFC: 8c22cf9b
Jan 30 2021, 8:21 AM
mckusick committed R10:1aa1ede1fd44: MFC: a63eae6 (authored by mckusick).
MFC: a63eae6
Jan 30 2021, 8:15 AM
mckusick added a reverting change for R10:2d4422e7991a: Eliminate lock order reversal in UFS ffs_unmount().: R10:1aa1ede1fd44: MFC: a63eae6.
Jan 30 2021, 8:15 AM
mckusick added a reverting change for R10:2d4422e7991a: Eliminate lock order reversal in UFS ffs_unmount().: R10:a63eae65ff87: Revert 2d4422e7991a, Eliminate lock order reversal in UFS ffs_unmount()..
Jan 30 2021, 8:02 AM
mckusick committed R10:a63eae65ff87: Revert 2d4422e7991a, Eliminate lock order reversal in UFS ffs_unmount(). (authored by mckusick).
Revert 2d4422e7991a, Eliminate lock order reversal in UFS ffs_unmount().
Jan 30 2021, 8:01 AM

Jan 26 2021

mckusick committed R10:8c22cf9b0997: Fix fsck_ffs incorrectly reporting "CANNOT READ BLK: NNNN" errors. (authored by mckusick).
Fix fsck_ffs incorrectly reporting "CANNOT READ BLK: NNNN" errors.
Jan 26 2021, 7:48 PM

Jan 16 2021

mckusick committed R10:79a5c790bdf0: Eliminate a locking panic when cleaning up UFS snapshots after a (authored by mckusick).
Eliminate a locking panic when cleaning up UFS snapshots after a
Jan 16 2021, 12:33 AM
mckusick committed R10:173779b98f10: Eliminate lock order reversal in UFS when unmounting filesystems (authored by mckusick).
Eliminate lock order reversal in UFS when unmounting filesystems
Jan 16 2021, 12:02 AM

Jan 12 2021

mckusick committed R10:2d4422e7991a: Eliminate lock order reversal in UFS ffs_unmount(). (authored by mckusick).
Eliminate lock order reversal in UFS ffs_unmount().
Jan 12 2021, 12:45 AM

Jan 7 2021

mckusick committed R10:5cc52631b3b8: Rewrite the disk I/O management system in fsck_ffs(8). Other than (authored by mckusick).
Rewrite the disk I/O management system in fsck_ffs(8). Other than
Jan 7 2021, 10:59 PM
mckusick accepted D28008: vfs: fix rangelock range in vn_rdwr() for IO_APPEND.

This change certainly fixes the problem though it write-locks far more than necessary.

Jan 7 2021, 5:18 AM
mckusick committed R10:c8a7a3ffe120: Fix bug in expanding lost+found direct blocks. (authored by mckusick).
Fix bug in expanding lost+found direct blocks.
Jan 7 2021, 12:31 AM

Jan 3 2021

mckusick committed R10:997f81af4316: The fsck_ffs program had previously only been able to expand the size (authored by mckusick).
The fsck_ffs program had previously only been able to expand the size
Jan 3 2021, 6:48 AM

Jan 1 2021

mckusick committed R10:41cf333f9b2a: MFC: Correct and add some comments. (authored by mckusick).
MFC: Correct and add some comments.
Jan 1 2021, 7:59 AM

Dec 31 2020

mckusick committed R10:68dc94c7d314: Correct and add some comments. (authored by mckusick).
Correct and add some comments.
Dec 31 2020, 11:32 PM

Dec 23 2020

mckusick accepted D27731: ffs: Avoid out-of-bounds accesses in the fs_active bitmap.

No change in actual running, but definitely correct change.

Dec 23 2020, 5:31 AM

Dec 18 2020

mckusick committed rS368773: Rename pass4check() to freeblock() and move from pass4.c to inode.c..
Rename pass4check() to freeblock() and move from pass4.c to inode.c.
Dec 18 2020, 11:28 PM

Dec 11 2020

mckusick accepted D27558: ffs: quiet -Wstrict-prototypes.
Dec 11 2020, 7:08 AM

Dec 9 2020

mckusick committed rS368494: MFC of 368396 and 368425..
MFC of 368396 and 368425.
Dec 9 2020, 10:37 PM

Dec 8 2020

mckusick committed rS368425: In ext2fs, BA_CLRBUF is used in ext2_balloc() not UFS_BALLOC()..
In ext2fs, BA_CLRBUF is used in ext2_balloc() not UFS_BALLOC().
Dec 8 2020, 12:49 AM

Dec 6 2020

mckusick committed rS368396: Document the BA_CLRBUF flag used in ufs and ext2fs filesystems..
Document the BA_CLRBUF flag used in ufs and ext2fs filesystems.
Dec 6 2020, 8:50 PM
mckusick accepted D27457: ufs: handle two more cases of possible VNON vnode returned from VFS_VGET()..

These updates look needed and correct.

Dec 6 2020, 12:36 AM

Nov 29 2020

mckusick accepted D27353: ffs: do not read full direct blocks if they are going to be overwritten..

Good to go.

Nov 29 2020, 10:12 PM

Nov 25 2020

mckusick requested changes to D27353: ffs: do not read full direct blocks if they are going to be overwritten..

The sentiment is correct, but logic fixes noted are needed.

Nov 25 2020, 4:39 AM

Nov 20 2020

mckusick added a comment to D27269: msdosfs: suspend around umount or remount rw->ro..

Belatedly, these changes look good and in particular get rid of VOP_SYNC(..., MNT_WAIT).

Nov 20 2020, 9:14 PM
mckusick committed rS367911: Only attempt a VOP_UNLOCK() when the vn_lock() has been successful..
Only attempt a VOP_UNLOCK() when the vn_lock() has been successful.
Nov 20 2020, 8:22 PM

Nov 17 2020

mckusick committed rS367751: MFC of 367045..
MFC of 367045.
Nov 17 2020, 6:04 AM
mckusick committed rS367750: MFC of 367035..
MFC of 367035.
Nov 17 2020, 6:00 AM
mckusick committed rS367749: MFC of 340927 and 367034..
MFC of 340927 and 367034.
Nov 17 2020, 5:48 AM

Nov 16 2020

mckusick accepted D27225: Make MAXPHYS tunable..

I have wanted this change for a long time. Thanks for doing it.

Nov 16 2020, 10:14 PM

Nov 14 2020

mckusick added a comment to D26912: RFC: Disk I/O priority support.

Have we reached any conclusions about whether to do any of the ideas suggested in this phabricator thread?

Nov 14 2020, 10:53 PM · cam
mckusick added a comment to D26964: ufs: end-of-life truncate should depend on dirent write.

I have thought about how to preserve the performance behavior aspects of r209717, but I haven't come up with how to do it. Here are a few thoughts.

  • There's the patch here that uses i_nlink instead of i_effnlink, which I think solves the problem I set out to solve, but probably reopens the problem from r209717.
  • We could do the above and add a chicken switch, like vfs.ffs.doasyncfree (vfs.ffs.doeagertrunc?).
  • I think, most ideally, we would just make all of the writes that happens in ffs_truncate for the end-of-life truncate depend on i_nlink reaching zero (via softdep, and either directly or indirectly). That way the thread doing the remove is still usually the one calling ffs_truncate and can be throttled. However I don't really know how to do this in code, and I'm unsure whether it's feasible (?).
  • As a hack, we could do some kind of proxy throttle. This would be something like, if we are inactivating a large file, or we are softdep_excess_items(D_DIRREM), then do some process_worklist_item() to do some of the flusher work.

Thoughts on how to proceed?

Nov 14 2020, 10:49 PM

Nov 6 2020

mckusick added a comment to D27054: Suspend all writeable local filesystems on power suspend..

Two questions.

Nov 6 2020, 6:09 PM

Nov 1 2020

mckusick accepted D26136: Handle LoR in flush_pagedep_deps()..

All looks good.

Nov 1 2020, 4:59 PM

Oct 31 2020

mckusick added a comment to D26964: ufs: end-of-life truncate should depend on dirent write.

! In D26964#603222, @rlibby wrote:

! In D26964#603106, @mckusick wrote:

I do like your new approach better as it is much clearer what is going on. I think that it may be sufficient to just make the last change in your delta where you switch it only doing the truncation when i_nlink falls to zero. The other actions taken when i_effnlink falls to zero should still be OK to be done then. As before, getting Peter Holm's testing is important.

Okay. I'll post the diff as you suggest, but I don't quite understand. Those other actions seem just to be doing a vn_start_secondary_write(). Is this so that when i_effnlink <= 0 but i_nlink > 0 and we have one of the IN_ change flags, that we use V_NOWAIT for the vn_start_secondary_write and possibly defer with VI_OWEINACT vs the V_WAIT we might use just above UFS_UPDATE?

My recollection is that the i_effnlink <= 0 when i_nlink > 0 got added because we were somehow missing getting VI_OWEINACT set. But looking through the code, I just cannot come up with a scenario where that is the case. So your original proposed change is probably correct and would save some extra unnecessary work.

Oct 31 2020, 11:07 PM
mckusick added a comment to D26136: Handle LoR in flush_pagedep_deps()..

This is an impressive piece of work, what a lot of effort to fix this LOR. Took a couple of hours to review, but overall looks good. A couple of minor inline comments.

Oct 31 2020, 10:36 PM

Oct 30 2020

mckusick added a comment to D26964: ufs: end-of-life truncate should depend on dirent write.
In D26964#601553, @kib wrote:

I am not sure about this approach. Note that vref()/usecount reference does not prevent the vnode reclaim. So for instance force umount results in vgone() which does inactivation and reclaim regardless of the active state (or rather does inactivation if the vnode is active). In this case, it seems to not fix the issue.

Also, typically SU does not rely on the _vnode_ state, workitems are attached to the metadata blocks owned by devvp.

Oct 30 2020, 11:21 PM
mckusick added a comment to D26964: ufs: end-of-life truncate should depend on dirent write.

Okay. I am definitely open to better solutions, especially if they fit the paradigm better.

In ufs_inactive, why do we look at i_effnlink at all? Why not just base the truncate on i_nlink? I think this could be another method of delaying the end-of-life truncate until after the write of the dirent, but without relying on a vnode reference. I think that might look like this:
https://github.com/rlibby/freebsd/commit/3b62c248f3377c47fb4bfa65a19b0f5390caec37
(Passes stress2's fs.sh and issue repros above.)

Oct 30 2020, 11:17 PM

Oct 27 2020

mckusick added a comment to D26964: ufs: end-of-life truncate should depend on dirent write.

You note that ``If we then crashed before the dirent write, we would recover with a state where the file was still linked, but had been truncated to zero. The resulting state could be considered corruption.'' The filesystem is not corrupted in the sense that it needs fsck to be run to clean it up. We simply end up with an unexpected result.

Oct 27 2020, 12:55 AM

Oct 25 2020

mckusick committed rS367045: Use proper type (ino_t) for inode numbers to avoid improper sign extention.
Use proper type (ino_t) for inode numbers to avoid improper sign extention
Oct 25 2020, 9:04 PM
mckusick committed rS367035: Filesystem utilities that modify the filesystem (growfs(8), tunefs(8),.
Filesystem utilities that modify the filesystem (growfs(8), tunefs(8),
Oct 25 2020, 1:36 AM
mckusick committed rS367034: Various new check-hash checks have been added to the UFS filesystem.
Various new check-hash checks have been added to the UFS filesystem
Oct 25 2020, 12:44 AM

Oct 23 2020

mckusick added a comment to D26912: RFC: Disk I/O priority support.

It would be trivial to request high priority for synchronous writes in bwrite() and if desired synchronous reads in bread(). That would have effects for several filesystems.

Oct 23 2020, 6:16 AM · cam

Oct 18 2020

mckusick added a comment to D26136: Handle LoR in flush_pagedep_deps()..

Added a couple of inline comments.

Oct 18 2020, 10:46 PM

Oct 3 2020

mckusick accepted D26596: ufs: restore uniqueness of st_dev.
Oct 3 2020, 8:27 PM

Sep 26 2020

mckusick committed rS366187: MFS of 366163 from stable/12 which is MFC of 365992 from head..
MFS of 366163 from stable/12 which is MFC of 365992 from head.
Sep 26 2020, 9:46 PM

Sep 25 2020

mckusick added a comment to D26511: Do not leak B_BARRIER..
In D26511#591360, @kib wrote:

The block being written with the barrier is a newly allocated block of inodes. The write is done asynchronously and the cylinder group is then updated to reflect that the additional inodes are available. The reason for the barrier is so that the cylinder group buffer with the newly expanded inode map cannot be written before the newly allocated set of inodes.

Since the incore cylinder group includes the newly created inodes, some other thread can come along and try to use one of those newly allocated inodes. but, it will block on the inode buffer until its write has completed.

The bug in this instance is that there is an assumption that the write cannot fail. Clearly this is a bad assumption. So, the correct fix is to not depend on the barrier write, but rather to create a callback that updates the cylinder group once the write of the new inodes has completed successfully.

In the specific case of kostik1316, doing that would deadlock the machine. Problem is that CoW write returned ENOSPC, which means that there is no way to correctly free space on the volume. I am not sure what do to there. Most likely any other write would also return ENOSPC, so in fact consistency of the volume is not too badly broken if we just fail there. If we start tracking the write as a dependency for cg write, then all that buffers add to the dirty space which eventually hang buffer subsystem.

I believe (based on Peter testing) that just erroring write allows us to unmount.

What we are trying to do where the barrier write is being used in UFS is expand the number of available inodes. It is OK to abandon the write of the zero'ed out inode block as the expansion can be put off to later. But, we must not update the cylinder group to say that these new inodes are available if we have not been able to zero them out. As it is currently written, the cylinder group is updated but the on-disk inodes are not zero'ed out. If the unmount succeeds in writing out the dirty buffers we will end up with a corrupted filesystem because fsck_ffs will try to check the non-zero'ed out inodes and raise numerous errors trying to correct the inconsistencies that arise from the random data in the uninitialzed inode block.

Sep 25 2020, 6:36 PM
mckusick committed rS366163: MFC of 365992.
MFC of 365992
Sep 25 2020, 5:14 PM
mckusick added a comment to D26511: Do not leak B_BARRIER..
In D26511#590951, @kib wrote:
In D26511#590229, @kib wrote:

As long as the buffer remains locked until it is successfully written, this should be fine.

Sorry, I do not fully understand you note. Do you mean that it is fine to have B_BARRIER set as far as buffer is not unlocked ? If not, could you please clarify.

We are depending on this being written before it can be used. If it were unlocked, then some other thread could get it and make use of it. See comment above use of babarrierwrite in sys/ufs/ffs/ffs_alloc.c.

I still do not understand what do you mean by 'use'. In the kostik1316 dump, most probable scenario was that babarrierwrite() for the inode block failed with ENOSPC, and then bufdone() does brelse() on the buffer. So it is unlocked, but this is somewhat unrelated to the issue of leaking B_BARRIER.

Sep 25 2020, 1:03 AM

Sep 23 2020

mckusick added a comment to D26511: Do not leak B_BARRIER..
In D26511#590229, @kib wrote:

As long as the buffer remains locked until it is successfully written, this should be fine.

Sorry, I do not fully understand you note. Do you mean that it is fine to have B_BARRIER set as far as buffer is not unlocked ? If not, could you please clarify.

We are depending on this being written before it can be used. If it were unlocked, then some other thread could get it and make use of it. See comment above use of babarrierwrite in sys/ufs/ffs/ffs_alloc.c.

Sep 23 2020, 10:25 PM

Sep 22 2020

mckusick committed rS365992: Add missing cylinder group check-hash updates when doing large expansions.
Add missing cylinder group check-hash updates when doing large expansions
Sep 22 2020, 3:57 AM

Sep 21 2020

mckusick accepted D26511: Do not leak B_BARRIER..

As long as the buffer remains locked until it is successfully written, this should be fine.

Sep 21 2020, 10:38 PM
mckusick committed rS365971: MFC of 365700.
MFC of 365700
Sep 21 2020, 7:26 PM

Sep 19 2020

mckusick committed rS365919: Update the libufs cgget() and cgput() interfaces to have a similar.
Update the libufs cgget() and cgput() interfaces to have a similar
Sep 19 2020, 10:49 PM
mckusick committed rS365912: The fsdb(8) utility uses the fsck_ffs(8) disk I/O interfaces, so.
The fsdb(8) utility uses the fsck_ffs(8) disk I/O interfaces, so
Sep 19 2020, 8:06 PM

Sep 13 2020

mckusick committed rS365700: In the newfs(8) utility, use the more appropriate sbwrite() and cgwrite().
In the newfs(8) utility, use the more appropriate sbwrite() and cgwrite()
Sep 13 2020, 10:58 PM

Sep 12 2020

mckusick accepted D26375: Move td_softdep_cleanup() from userret() to ast().

This change looks reasonable to me as at least for amd64 every path out of the kernel appears to check TDF_ASTPENDING and calls ast() if set.

Sep 12 2020, 6:14 AM

Sep 1 2020

mckusick accepted D26289: Remove risky compatability with old kernels..

It was a horrible hack at the time and should have been tossed decades ago.

Sep 1 2020, 11:17 PM

Aug 31 2020

mckusick committed rS364983: MFC of 364895.
MFC of 364895
Aug 31 2020, 5:25 AM

Aug 29 2020

mckusick added a comment to D25969: Events for mount, remount and umount in devdAdd remount vfs event, publish mount, remount and unmount events..

A new review? If so, I suggest that you close this one and give a pointer to the new one.

Aug 29 2020, 10:02 PM

Aug 27 2020

mckusick committed rS364895: Add a comment to clarify when and why cached names are deleted.
Add a comment to clarify when and why cached names are deleted
Aug 27 2020, 10:15 PM
mckusick added a comment to D25969: Events for mount, remount and umount in devdAdd remount vfs event, publish mount, remount and unmount events..

What is the status with this change?

Aug 27 2020, 10:01 PM

Aug 26 2020

mckusick added a comment to D26136: Handle LoR in flush_pagedep_deps()..

The get_parent_vp() function seems to be handling two different problems.
In its first instance it is dealing with locking its parent. Here we already have the function vn_vget_ino() which presumably could be used to handle this situation.
In its second and third instances it is avoiding a LOR of acquiring an inode lock while holding a buffer lock. Here we need a function like the proposed get_parent_vp(). However, we will no longer need the first (vp) argument as we are acquiring a child inode so do not have to release the already held parent inode before acquiring the child inode.

Aug 26 2020, 12:07 AM

Aug 15 2020

mckusick committed rS364262: Use the sbput() function to write alternate superblocks so that.
Use the sbput() function to write alternate superblocks so that
Aug 15 2020, 9:40 PM

Aug 8 2020

mckusick accepted D25969: Events for mount, remount and umount in devdAdd remount vfs event, publish mount, remount and unmount events..

This change will provide the interface that we will need to notify daemon processes for our forcible unmount and forcible downgrade to read-only as well as re-establishment of read-write after a successful background fsck.

Aug 8 2020, 4:19 AM

Jul 22 2020

mckusick accepted D25759: Avoid reading one byte before the path buffer..

I concur with the proposed change and also agree that cem's suggestion is a good one.

Jul 22 2020, 4:32 AM

Jul 21 2020

mckusick committed rS363405: MFC of 362369 (by Lorenzo Salvadore) and 363192.
MFC of 362369 (by Lorenzo Salvadore) and 363192
Jul 21 2020, 11:23 PM

Jul 14 2020

mckusick closed D25660: Update to D25266 bin/ps: Make the rtprio option actually show realtime priorities.
Jul 14 2020, 6:57 PM
mckusick committed rS363192: Update to D25266, bin/ps: Make the rtprio option actually show.
Update to D25266, bin/ps: Make the rtprio option actually show
Jul 14 2020, 6:57 PM
mckusick requested review of D25660: Update to D25266 bin/ps: Make the rtprio option actually show realtime priorities.
Jul 14 2020, 7:31 AM

Jul 13 2020

mckusick requested changes to D25599: vfs_syscalls: Call VFS_SYNC with MNT_WAIT argument..

This should not be done as written as it can cause a denial of service (infinite loop) as described in my previous comment.

Jul 13 2020, 11:10 PM
mckusick closed D2068: add mahrens as committer.

Done.

Jul 13 2020, 11:08 PM

Jul 10 2020

mckusick added a comment to D25599: vfs_syscalls: Call VFS_SYNC with MNT_WAIT argument..

If data is being written to the filesystem faster than the disk can write it then a sync with MNT_WAIT will never finish. The only safe way to use sync with MNT_WAIT is to first suspend the filesystem to create a finite number of write operations that need to be done.

Jul 10 2020, 9:15 PM

Jul 9 2020

mckusick committed rS363056: MFC of 362560.
MFC of 362560
Jul 9 2020, 7:12 PM

Jul 6 2020

mckusick added a comment to D25579: (lookup 4) ufs: add support for lockless lookup.

I cannot speak to the correctness of the whole patch, but looking over D25577, D25578, and this one, D25579, I see nothing that looks incorrect.

Jul 6 2020, 11:03 PM

Jun 30 2020

mckusick requested changes to D25073: Define M_UFSMNT in ffs_subr.c.

Per the above commentary, this change should be withdrawn.

Jun 30 2020, 6:25 PM

Jun 24 2020

mckusick added a comment to D25073: Define M_UFSMNT in ffs_subr.c.

Having read Chuck's argument, I agree with it. I was thinking that the g_label_ufs.c routines passed in M_UFSMNT as their malloc type. But they do not. They use M_GEOM malloc type. So there is no need for them to have an definition for M_UFSMNT.

Jun 24 2020, 9:36 PM
mckusick added a comment to D25403: Fix fallout from the emancipation of dump(8) workers.

Thanks for this cleanup. I found the previous transformation grating for the reasons that you listed.

Jun 24 2020, 4:34 PM
mckusick accepted D25073: Define M_UFSMNT in ffs_subr.c.

This looks like a reasonable change to me.

Jun 24 2020, 6:22 AM
mckusick added a comment to D25404: ufs: a fix for sync write.

I believe that the existing test already has this covered. The test (resid > uio->uio_resid) is checking that any data has been written. In the typical case this is at the end of the file and the size will have increased. But if the write was in the middle of a file filling in a hole then this test will catch that and cause the inode to be written.

Jun 24 2020, 6:02 AM

Jun 23 2020

mckusick committed rS362561: Optimize g_journal's superblock update by noting that the summary.
Optimize g_journal's superblock update by noting that the summary
Jun 23 2020, 9:44 PM
mckusick committed rS362560: Correctly describe the return values for the libufs library sbget().
Correctly describe the return values for the libufs library sbget()
Jun 23 2020, 9:37 PM
mckusick committed rS362559: The libufs library needs to track and free the new fs_si structure.
The libufs library needs to track and free the new fs_si structure
Jun 23 2020, 9:28 PM
mckusick committed rS362558: Align comments in struct uufsd structure. No semantic change..
Align comments in struct uufsd structure. No semantic change.
Jun 23 2020, 9:17 PM

Jun 19 2020

mckusick committed rS362418: Allocate an fs_summary_info structure when creating a UFS filesystem.
Allocate an fs_summary_info structure when creating a UFS filesystem
Jun 19 2020, 11:33 PM
mckusick added a comment to D25266: bin/ps: Make the rtprio option actually show realtime priorities.

Interesting that I never added myself to the committers-src.dot file.
For reference, the file that actually controls access to doing src commits is /usr/src/svnadmin/conf/access.
For interesting statistics on the history of commits, fetch these files:

fetch https://people.freebsd.org/~rodrigo/commits-base.txt
fetch https://people.freebsd.org/~rodrigo/commits-doc.txt
fetch https://people.freebsd.org/~rodrigo/commits-ports.txt

I agree that there should be documentation of MFC guidelines somewhere.
For a change of this sort an MFC delay in the range of 1-2 weeks is reasonable.

Jun 19 2020, 3:56 AM