From owner-freebsd-fs@FreeBSD.ORG Sun Jun 19 21:54:36 2011 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 D3194106566C; Sun, 19 Jun 2011 21:54:36 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 65CC28FC16; Sun, 19 Jun 2011 21:54:36 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 32A4C179D3E; Sun, 19 Jun 2011 23:54:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pyuKRrgnmp21; Sun, 19 Jun 2011 23:54:32 +0200 (CEST) Received: from [10.9.8.1] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 39747179D34; Sun, 19 Jun 2011 23:54:30 +0200 (CEST) Message-ID: <4DFE7015.8020205@FreeBSD.org> Date: Sun, 19 Jun 2011 23:54:29 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Matthias Andree References: <201102221550.p1MFo9Ld054161@freefall.freebsd.org> In-Reply-To: <201102221550.p1MFo9Ld054161@freefall.freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/154930: [zfs] cannot delete/unlink file from full volume -> ENOSPC 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: Sun, 19 Jun 2011 21:54:36 -0000 Some more information on this: Here is a OpenSolaris forums entry: http://opensolaris.org/jive/thread.jspa?threadID=62037 This is described in Illumos issues as well: https://www.illumos.org/issues/412 This is quite a serious problem of the ZFS implementation - to delete a file or a snapshot, you may need free space! I am quoting Garett D'Amore: "The problem is that with copy-on-write, when you delete a file you must create a new copy of the meta data which means a new tree, ultimately. Its not possible to avoid this, but it is possible that we should ultimately be able to have a reserve, and only allow operations which will ultimately remove data once the pool is reduced to nothing more than this reserve." Before we have a "reserve" implementation, the only workaround I found is creating an empty dataset with some reserved space (which you can free in a case of emergency), e.g.: zfs create -o mountpoint=none -o reservation=10M tank/reserve Dňa 22.02.2011 16:50, Matthias Andree wrote / napísal(a): > The following reply was made to PR kern/154930; it has been noted by GNATS. > > From: Matthias Andree > To: Martin Matuska > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/154930: [zfs] cannot delete/unlink file from full volume > -> ENOSPC > Date: Tue, 22 Feb 2011 16:06:47 +0100 > > Am 22.02.2011 15:30, schrieb Martin Matuska: > > I was unable to reproduce your problem. > > > > But I was able to reproduce a different situation: > > - on a dataset with one or more snapshots I am unable to delete files > > (ENOSPC) if the dataset got full. > > > > If this is your case, then: > > - deleting files does not unlink them from the snapshot. > > - you must first delete a specific snapshot (or all snapshots linking > > the file) to free space. > > Hi Martin, > > no snapshots were ever used on the zpools or zfs volumes -- I had > checked that previously. Only truncation of a 20 M file would allow me > to delete files. > > Best regards > Matthias > > -- > Matthias Andree > ports committer > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Martin Matuska FreeBSD committer http://blog.vx.sk