From owner-freebsd-fs@FreeBSD.ORG Sat Jun 26 16:29:43 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B284F106566C for ; Sat, 26 Jun 2010 16:29:43 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 46D5B8FC12 for ; Sat, 26 Jun 2010 16:29:42 +0000 (UTC) Received: by wwb24 with SMTP id 24so3513682wwb.13 for ; Sat, 26 Jun 2010 09:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yjDEW4PECMGxNjUboHEO163bb8NMr4yq97Nqj/S5d68=; b=bOFTNl29/HHZKc+GPGphRuKs78cGcCCrKgB5TQM5DMZ1CFuVhoQqlSn5sqd69w2F5T e7T3PDUkYZe3zPYKuwW8QqYL4tMoKj+YRI3V2Y1URId3U50uINpDIKHpPfwc5qPrYFD8 pbPLbaPX+VZUFe7Lxt0ZTAgw2H01aAeNP/+e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f5MeT5Xf3EhH6p/ZpPgjbZcjria4w9zf4fzcXnIgwTiyCDbxmafw5QTVDaLXRWxaCt 5qCYgYtX4Yr1xuxV5L765DQSsfRNw/t7tAUlSlreY5qPkyI3VCsF6+yj1o4Bxz4fRPGu rKCyrtY9bmu4MdxuIChoUuU0M2HMuHeNT4vtQ= MIME-Version: 1.0 Received: by 10.227.128.213 with SMTP id l21mr1852944wbs.133.1277569781958; Sat, 26 Jun 2010 09:29:41 -0700 (PDT) Received: by 10.216.28.200 with HTTP; Sat, 26 Jun 2010 09:29:41 -0700 (PDT) In-Reply-To: <20100626141038.0d9f488a@r500.local> References: <20100625231708.GB29793@server.vk2pj.dyndns.org> <20100626141038.0d9f488a@r500.local> Date: Sat, 26 Jun 2010 18:29:41 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: mdconfig on ZFS leaks disk space X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 16:29:43 -0000 what is your svn rev ? because r208869: Fix freeing space after deleting large files with holes dated: Sun Jun 6 13:08:36 2010 2010/6/26 Fabian Keil : > Peter Jeremy 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. =A0Has 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 s= ize 2048 >> =A0 =A0 =A0 =A0 using 45661 cylinder groups of 183.72MB, 11758 blks, 235= 52 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 =A08319620678 =A04 7654051020 0% =A02 1075407868 =A0 =A00% =A0 = /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. =A0lsof showed no references to the space. =A0Whilst >> there were snapshots of /tmp, none had been taken since /tmp/space >> was created. =A0I deleted them anyway to no effect. > > I can't reproduce this with Martin Matuska's ZFS v16 patch: > > fk@r500 /tank/sparse-file-test $df -h ./ > Filesystem =A0 =A0 =A0 =A0 =A0 =A0 =A0 Size =A0 =A0Used =A0 Avail Capacit= y =A0Mounted on > tank/sparse-file-test =A0 =A0 62G =A0 =A0932M =A0 =A0 61G =A0 =A0 1% =A0 = =A0/tank/sparse-file-test > fk@r500 /tank/sparse-file-test $sudo rm space > fk@r500 /tank/sparse-file-test $df -h ./ > Filesystem =A0 =A0 =A0 =A0 =A0 =A0 =A0 Size =A0 =A0Used =A0 Avail Capacit= y =A0Mounted on > tank/sparse-file-test =A0 =A0 62G =A0 =A0 96K =A0 =A0 62G =A0 =A0 0% =A0 = =A0/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 >