From owner-freebsd-fs@FreeBSD.ORG Thu Jul 4 00:00:02 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D651E3D for ; Thu, 4 Jul 2013 00:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB771F91 for ; Thu, 4 Jul 2013 00:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r64001Gi076819 for ; Thu, 4 Jul 2013 00:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r64001v6076818; Thu, 4 Jul 2013 00:00:01 GMT (envelope-from gnats) Date: Thu, 4 Jul 2013 00:00:01 GMT Message-Id: <201307040000.r64001v6076818@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: "Steven Hartland" Subject: Re: kern/180236: [zfs] [nullfs] Leakage free space using ZFS with nullfs on 9.1-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Steven Hartland List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 00:00:02 -0000 The following reply was made to PR kern/180236; it has been noted by GNATS. From: "Steven Hartland" To: , "Ivan Klymenko" Cc: Subject: Re: kern/180236: [zfs] [nullfs] Leakage free space using ZFS with nullfs on 9.1-STABLE Date: Thu, 4 Jul 2013 00:58:13 +0100 Looks like nullfs isn't cleaning up correctly in the case where a rename colides with an existing file hence results in an implicit remove. This can be seen in the zdb output for the volume in that before the unmount all the plain file entries still exist but after the unmount of nullfs they are gone. In addition to this there may be an issue with the ZFS delete queue as, while after unmounting the nullfs the file entries do disappear the size of the delete queue doesn't seem to clear down properly. Dataset testpool/nullfs [ZPL], ID 40, cr_txg 19, 2.41M, 7 objects ZIL header: claim_txg 0, claim_blk_seq 0, claim_lr_seq 0 replay_seq 0, flags 0x0 Object lvl iblk dblk dsize lsize %full type 0 7 16K 16K 15.0K 32.0M 0.01 DMU dnode -1 1 16K 512 1K 512 100.00 ZFS user/group used -2 1 16K 512 1K 512 100.00 ZFS user/group used 1 1 16K 1K 1K 1K 100.00 ZFS master node 2 1 16K 512 1K 512 100.00 SA master node 3 3 16K 16K 2.38M 7.45M 100.00 ZFS delete queue 4 1 16K 512 1K 512 100.00 ZFS directory 5 1 16K 1.50K 1K 1.50K 100.00 SA attr registration 6 1 16K 16K 7.00K 32K 100.00 SA attr layouts 7 1 16K 512 1K 512 100.00 ZFS directory This is an area I'm not familiar with yet, so it may be this is expected but it should be checked. Regards Steve