Bug 180236 - [zfs] [nullfs] Leakage free space using ZFS with nullfs on 9.1-STABLE
Summary: [zfs] [nullfs] Leakage free space using ZFS with nullfs on 9.1-STABLE
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-03 14:40 UTC by Ivan Klymenko
Modified: 2014-06-16 08:05 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Klymenko 2013-07-03 14:40:00 UTC
Leakage free space using ZFS with nullfs on 9.1-STABLE
I have a system with the installed version
uname -a
FreeBSD nonamehost 9.1-STABLE FreeBSD 9.1-STABLE #13: Wed Jun 19 20:16:00 UTC 2013     root@nonamehost:/usr/src/obj/usr/src/sys/GENERIC amd64

zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
rpool                    10.0G   777G    31K  none
rpool/root               10.0G   777G  3.38G  legacy

Fix: 

I do not know.
How-To-Repeat: carry out preparatory actions
#****************************#
mkdir -p /mnt/nullfs
zfs create rpool/root/nullfs
zfs set mountpoint=/usr/nullfs rpool/root/nullfs
mount -t nullfs /usr/nullfs/ /mnt/nullfs/
#****************************#

zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
rpool                    10.0G   777G    31K  none
rpool/root               10.0G   777G  3.38G  legacy
rpool/root/nullfs          31K   777G    31K  /usr/nullfs

df -h
Filesystem                                           Size    Used   Avail Capacity  Mounted on
rpool/root                                           780G    3.4G    777G     0%    /
devfs                                                1.0k    1.0k      0B   100%    /dev
zswap                                                1.2G     31k    1.2G     0%    /zswap
devfs                                                1.0k    1.0k      0B   100%    /var/named/dev
rpool/root/nullfs                                    777G     31k    777G     0%    /usr/nullfs
/usr/nullfs                                          777G     31k    777G     0%    /mnt/nullfs

run the following script
#****************************#
#!/bin/sh

while [ 1 ]; do
    [ -f "/tmp/stop" ] && exit
    echo "1" > /mnt/nullfs/a
    mv /mnt/nullfs/a /mnt/nullfs/b
done
#****************************#

two minutes later we get the following result

df -h | grep nullfs
rpool/root/nullfs                                    776G    127M    776G     0%    /usr/nullfs
/usr/nullfs                                          776G    127M    776G     0%    /mnt/nullfs
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-07-03 21:36:46 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Steven Hartland freebsd_committer freebsd_triage 2013-07-04 00:58:13 UTC
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
Comment 3 dfilter service freebsd_committer freebsd_triage 2013-07-04 20:01:25 UTC
Author: kib
Date: Thu Jul  4 19:01:18 2013
New Revision: 252714
URL: http://svnweb.freebsd.org/changeset/base/252714

Log:
  The tvp vnode on rename is usually unlinked.  Drop the cached null
  vnode for tvp to allow the free of the lower vnode, if needed.
  
  PR:	kern/180236
  Tested by:	smh
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 week

Modified:
  head/sys/fs/nullfs/null_vnops.c

Modified: head/sys/fs/nullfs/null_vnops.c
==============================================================================
--- head/sys/fs/nullfs/null_vnops.c	Thu Jul  4 18:59:58 2013	(r252713)
+++ head/sys/fs/nullfs/null_vnops.c	Thu Jul  4 19:01:18 2013	(r252714)
@@ -554,6 +554,7 @@ null_rename(struct vop_rename_args *ap)
 	struct vnode *fvp = ap->a_fvp;
 	struct vnode *fdvp = ap->a_fdvp;
 	struct vnode *tvp = ap->a_tvp;
+	struct null_node *tnn;
 
 	/* Check for cross-device rename. */
 	if ((fvp->v_mount != tdvp->v_mount) ||
@@ -568,7 +569,11 @@ null_rename(struct vop_rename_args *ap)
 		vrele(fvp);
 		return (EXDEV);
 	}
-	
+
+	if (tvp != NULL) {
+		tnn = VTONULL(tvp);
+		tnn->null_flags |= NULLV_DROP;
+	}
 	return (null_bypass((struct vop_generic_args *)ap));
 }
 
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 4 Steven Hartland freebsd_committer freebsd_triage 2013-07-04 20:14:46 UTC
State Changed
From-To: open->patched

This is now addressed by r252714 
(http://svnweb.freebsd.org/changeset/base/252714) in head thanks to kib
Comment 5 Ivan Klymenko 2013-07-05 12:17:40 UTC
I confirm - this patch fixes this problem by 9.1-STABLE

Thanks to all.

PR kern/180236 may be closed.
Comment 6 dfilter service freebsd_committer freebsd_triage 2013-07-11 05:48:02 UTC
Author: kib
Date: Thu Jul 11 04:47:44 2013
New Revision: 253183
URL: http://svnweb.freebsd.org/changeset/base/253183

Log:
  MFC r252714:
  The tvp vnode on rename is usually unlinked.  Drop the cached null
  vnode for tvp to allow the free of the lower vnode, if needed.
  
  PR:	kern/180236

Modified:
  stable/9/sys/fs/nullfs/null_vnops.c
Directory Properties:
  stable/9/sys/   (props changed)
  stable/9/sys/fs/   (props changed)

Modified: stable/9/sys/fs/nullfs/null_vnops.c
==============================================================================
--- stable/9/sys/fs/nullfs/null_vnops.c	Thu Jul 11 03:57:53 2013	(r253182)
+++ stable/9/sys/fs/nullfs/null_vnops.c	Thu Jul 11 04:47:44 2013	(r253183)
@@ -554,6 +554,7 @@ null_rename(struct vop_rename_args *ap)
 	struct vnode *fvp = ap->a_fvp;
 	struct vnode *fdvp = ap->a_fdvp;
 	struct vnode *tvp = ap->a_tvp;
+	struct null_node *tnn;
 
 	/* Check for cross-device rename. */
 	if ((fvp->v_mount != tdvp->v_mount) ||
@@ -568,7 +569,11 @@ null_rename(struct vop_rename_args *ap)
 		vrele(fvp);
 		return (EXDEV);
 	}
-	
+
+	if (tvp != NULL) {
+		tnn = VTONULL(tvp);
+		tnn->null_flags |= NULLV_DROP;
+	}
 	return (null_bypass((struct vop_generic_args *)ap));
 }
 
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 7 Ivan Klymenko 2014-01-09 10:27:31 UTC
This PR can be closed.

Thanks!