mdconfig on ZFS leaks disk space

[Fabian Keil]

Peter Jeremy <peterjeremy at acm.org> wrote:

> I recently did a quick experiment to create an 8TB UFS filesystem
> via mdconfig and after destroying the md and deleting the file,
> the disk space used by the md was not returned - even after a
> reboot.  Has anyone else seen this?
> 
> I was using a 8.1-prelease/amd64 with everything on ZFS v14 and did:
> 
> # truncate -s 8T /tmp/space
> # mdconfig -a -t vnode -f /tmp/space
> # newfs /dev/md0
> /dev/md0: 8388608.0MB (17179869184 sectors) block size 16384, fragment size 2048
>         using 45661 cylinder groups of 183.72MB, 11758 blks, 23552 inodes.
> 
> This occupied ~450MB on /tmp which uses lzjb compression.
> 
> # fsck -t ufs /dev/md0
> needed ~550MB VSZ and had ~530MB resident by the end.
> 
> # mount /dev/md0 /mnt
> # df -k /mnt
> /dev/md0  8319620678  4 7654051020 0%  2 1075407868    0%   /mnt
> 
> I then copied a random collection of files into /mnt, boosting the
> size of /tmp/space to ~880MB.
> 
> # umount /mnt
> # fsck -t ufs /dev/md0
> # mdconfig -d -u 0
> # rm /tmp/space
> 
> At this point, 'df' on /tmp reported 881MB used whilst 'du' on /tmp
> report 1MB used.  lsof showed no references to the space.  Whilst
> there were snapshots of /tmp, none had been taken since /tmp/space
> was created.  I deleted them anyway to no effect.

I can't reproduce this with Martin Matuska's ZFS v16 patch:

fk at r500 /tank/sparse-file-test $df -h ./
Filesystem               Size    Used   Avail Capacity  Mounted on
tank/sparse-file-test     62G    932M     61G     1%    /tank/sparse-file-test
fk at r500 /tank/sparse-file-test $sudo rm space 
fk at r500 /tank/sparse-file-test $df -h ./
Filesystem               Size    Used   Avail Capacity  Mounted on
tank/sparse-file-test     62G     96K     62G     0%    /tank/sparse-file-test

The pool is still v14.

I thought I remembered reports on zfs-discuss@ about a known bug with
leaked disk space after deleting sparse files that's supposed to be
fixed in latter ZFS versions, but so far I only found reports about
a similar problem with sparse volumes, so maybe I'm mistaken.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20100626/da644329/signature.pgp