Date: Thu, 4 Jul 2013 10:44:54 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Konstantin Belousov" <kostikbel@gmail.com> Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/180236: [zfs] [nullfs] Leakage free space using ZFS with nullfs on 9.1-STABLE Message-ID: <0F8371633F6B496B87285D660FAF205B@multiplay.co.uk> References: <201307040000.r64001v6076818@freefall.freebsd.org> <20130704041539.GE91021@kib.kiev.ua> <20130704083641.GK91021@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Konstantin Belousov" <kostikbel@gmail.com>
On Thu, Jul 04, 2013 at 07:15:39AM +0300, Konstantin Belousov wrote:
> > On Thu, Jul 04, 2013 at 12:00:01AM +0000, Steven Hartland wrote:
> > > The following reply was made to PR kern/180236; it has been noted by GNATS.
> > >
> > > From: "Steven Hartland" <smh@freebsd.org>
> > > To: <bug-followup@freebsd.org>,
> > > "Ivan Klymenko" <fidaj@ukr.net>
> > > 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.
> >
> > Can you demonstrate the scenario of the problem, e.g. using the basic
> > filesystem commands, like cp(1), mv(1) ? Does the issue reproduce
> > on UFS ?
>
>
> Ok, the following patch fixed the nullfs leakage for me (I tested over
> the UFS).
>
> diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c
> index 6ff15ee..70402e3 100644
> --- a/sys/fs/nullfs/null_vnops.c
> +++ b/sys/fs/nullfs/null_vnops.c
> @@ -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));
> }
Confirmed this fixes the issue.
I believe there's still a ZFS leak being triggered in the delete
queue before this nullfs fix, which will result in space not being
freed but with patch no further leaks occur.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0F8371633F6B496B87285D660FAF205B>