From owner-svn-src-head@FreeBSD.ORG Wed Oct 27 22:33:19 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F95106566C; Wed, 27 Oct 2010 22:33:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id AA9138FC13; Wed, 27 Oct 2010 22:33:18 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 17991A683DE; Thu, 28 Oct 2010 06:33:17 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id jli3LUb0jJLt; Thu, 28 Oct 2010 06:33:08 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id B124CA683D2; Thu, 28 Oct 2010 06:33:05 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Q273MbKmQIOm7fXgqrOfdl240PeYhIpYUzp9ooFekkLZCrKeo3KoRumcf9y3x7JmF O+8NrwrDrNlKqoB5McGnA== Message-ID: <4CC8A89D.5070909@delphij.net> Date: Wed, 27 Oct 2010 15:33:01 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.14) Gecko/20101020 Thunderbird/3.0.9 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Alexander Best References: <201010271848.o9RImNSR019344@svn.freebsd.org> <20101027212601.GA78062@freebsd.org> <4CC899C3.7040107@FreeBSD.org> <20101027214822.GA82697@freebsd.org> In-Reply-To: <20101027214822.GA82697@freebsd.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, Doug Barton , src-committers@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: svn commit: r214431 - head/bin/rm X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 22:33:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/27/10 14:48, Alexander Best wrote: > On Wed Oct 27 10, Doug Barton wrote: >> On 10/27/10 14:26, Alexander Best wrote: >>> are in fact COW fs the only exception where the -P flag won't work? before >>> r213582 LFS was mentioned here and that the block size must be fixed. >>> also the comment in rm.c says that -P won't work for any logging file >>> systems. >>> i'm not a fs expert, but i think mentioning that -P won't work for COW fs >>> isn't >>> enough. >> >> What may be a better approach is to confirm the fs' that DO work, list >> them, and then add something to the effect of, "This feature is unlikely >> to work on other file systems." > > i don't think that's a good approach, because then the rm(1) has to be changed > everytime freebsd gets a new fs which works with the -P option. i think it's > better to list which fs semantics DON'T work. so if freebsd gets a new fs, > users simply have to know which semantics the new fs is based on and can decide > for themselves whether the -P switch will work or not. > > so far the -P option doesn't seem to work for: > > - COW fs and/or > - fs with a variable block size and/or > - fs which do journaling > > please correct me if i got anything wrong. so i think having such a list in the > rm(1) manual would be very nice (maybe improving the comment in rm.c too). I think what really defeats -P is the fact that the file system or underlying data storage would not overwrite data on a file at sync(). COW is of course one of the case, journaling MAY defeat -P but is not guaranteed. FS with variable block size - I believe this really depends on the implementation. If I understood the code correctly, UFS, UFS+SU, UFS+SUJ, msdosfs and ext2fs supports rm -P as long as they are not being put on gjournal'ed disk, ZFS zvol, etc., and no snapshot is being used. It seems to be hard for me to conclude all cases in short, plain English but I'm all for improvements to the manual page to describe that in an elegant and precise manner. Maybe something like: =============== BUGS The -P option assumes that the underlying storage overwrites file block when data is written on existing offset. Several factors including the file system and its backing store could defeat the assumption, this includes, but is not limited to file systems that uses Copy-On-Write strategy (e.g. ZFS or UFS when snapshot is being used), or backing datastore that does journaling, etc. In addition, only regular files are overwritten, other types of files are not. =============== Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMyKicAAoJEATO+BI/yjfBElYIAMP70g1a+YheuKD14NXugVTU sG4KEWAjRSZCe808f46AXU+wJePnRFkYVKD+A+6aH63y/r2V0e3CVMUYZZXr4l/d HJRnZjJK9e/YJv8pcCpq7PgnmPzMa4m4BQNYVJoNGbPd75V27wMi3hgBzzPrJxWL aBuB31hpU32PcpvzQgBPLiNzjEuLRq5be42HjgTPT1qGwSMEQcLgXOfG9l6TS27s I5n5KPU7dEFt0Z+3ljQM+F3Fk2wmy/EOAeRcZL89xvFZIAYmtVrL3UcniHALPRSn CAbGrNpCbvh2RZvJX1Cwu3H+PVIlIcl2uG/aiOEC7m/tA29LfPPXG0IzUN9qVLc= =LQen -----END PGP SIGNATURE-----