Date: Thu, 4 Jul 2013 00:00:01 GMT From: "Steven Hartland" <smh@freebsd.org> To: freebsd-fs@FreeBSD.org Subject: Re: kern/180236: [zfs] [nullfs] Leakage free space using ZFS with nullfs on 9.1-STABLE Message-ID: <201307040000.r64001v6076818@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307040000.r64001v6076818>