From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 08:53:12 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0639F16A41F; Sat, 24 Sep 2005 08:53:12 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B24C43D4C; Sat, 24 Sep 2005 08:53:11 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j8O8r1O7090514; Sat, 24 Sep 2005 01:53:05 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509240853.j8O8r1O7090514@gw.catspoiler.org> Date: Sat, 24 Sep 2005 01:53:01 -0700 (PDT) From: Don Lewis To: Tor Egge In-Reply-To: <200509240741.j8O7fZca090425@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: scottl@FreeBSD.org, current@FreeBSD.org, mckusick@FreeBSD.org Subject: Re: soft updates / background fsck directory link count bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 08:53:12 -0000 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.