Re: soft updates / background fsck directory link count bug

On 24 Sep, Don Lewis wrote:
> On 24 Sep, Tor Egge wrote:

>> ufs_dirremmove() calls softdep_setup_remove() which sets up the
>> softupdates dependencies for reducing di_nlink on disk for leaf and
>> parent directory when it's safe to do so (i.e. after the directory
>> entry referencing the leaf directory has been cleared on disk).  See
>> code in reassignbuf() for various delays before the syncer process
>> pushes the dirty buffers to disk.
> 
> Ok, now I see the code at the end of handle_workitem_remove() that
> reuses the struct dirrem to decrement the link count of the parent
> directory.  For some reason the second handle_workitem_remove() call is
> getting deferred indefinitely.

I believe the problem is that handle_workitem_remove() is putting the
the dirrem on the inodep inowait list, but it is never getting moved to
the inodep bufwait list because ffs_update() and
softdep_update_inodeblock() are not getting called for the leaf
directory after the dirrem is put on the inowait list if the link count
is too large.

In the normal case, it appears that the dirrem migration is triggered
when the inode is zeroed in ufs_inactive(), which happens when the first
call to handle_workitem_remove() calls vput().

Perhaps the dirrem should be put on the inowait list before the call to
ffs_truncate().

>> The background fsck found the the di_nlink value being 3 on the parent
>> directory and issued an FFS_ADJ_REFCNT sysctl to reduce it by one,
>> having no knowledge about the pending dirrem dependency.  See
>> sysctl_ffs_fsck() for the handling of that sysctl.
>> 
>> After background fsck has run and the dirrem dependency has been
>> processed, the link counts for the parent directory are both 1.
> 
> Yup.
> 
> Even without the indefinite deferral problem, it seems to me that
> updating either file or directory link counts in background fsck is
> hazardous unless the directory slot updates and link count updates can
> be guaranteed to be consistent in the snapshot.

I just re-read the section on snapshots in _The Design and
Implementation of the FreeBSD Operating System_ and it says that the
file system should be synced when the snapshot is created, so this
shouldn't be a problem.