From owner-svn-src-all@FreeBSD.ORG Thu Oct 28 07:55:46 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82781065698; Thu, 28 Oct 2010 07:55:45 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C97988FC0A; Thu, 28 Oct 2010 07:55:44 +0000 (UTC) Received: by fxm17 with SMTP id 17so1667266fxm.13 for ; Thu, 28 Oct 2010 00:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=JoYKgNc12xXkPiut6QkDPLgzKO3JsCXyfLWvct/OBTo=; b=fBMW5bQykTqnDfbPDI729nTuYosvFV16xaYoowYAfsmgpEbsMYWMv47kVBwJD0Eo66 ItO2gIe5xj18adks1QlFV2+04H++9cDOrCQwdEGL1jKx+jzvX/iFsHlu4slwDXMD5opF ag40s3dLvD+g8ad2Ow/uDlCYp0llJAZlzGmVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=R4d/Y9gSlDogBe1BJGMI39O4fwAYchbFNuGS/UBCW6COt5hFju7M/bNZK4ehuQGhjB fSa3T/WYVyIExdk+oeIMsFjqVbXf+qNrb7YZB1xk4OGE9GrbBNRmXrmvgIGHkREcQPQs 3yDrfD9ddw+Jc80APXto6AEXbCmEtKInf33gA= Received: by 10.223.78.199 with SMTP id m7mr3597858fak.11.1288252543530; Thu, 28 Oct 2010 00:55:43 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3401.dip.t-dialin.net [87.142.52.1]) by mx.google.com with ESMTPS id p18sm335237faa.16.2010.10.28.00.55.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 00:55:41 -0700 (PDT) Date: Thu, 28 Oct 2010 09:55:38 +0200 From: Gary Jennejohn To: Bruce Evans Message-ID: <20101028095538.24147119@ernst.jennejohn.org> In-Reply-To: <20101028152418.A916@besplex.bde.org> References: <201010271848.o9RImNSR019344@svn.freebsd.org> <20101027212601.GA78062@freebsd.org> <4CC899C3.7040107@FreeBSD.org> <20101027214822.GA82697@freebsd.org> <4CC8A89D.5070909@delphij.net> <20101028152418.A916@besplex.bde.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Doug Barton , d@delphij.net, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-head@FreeBSD.org, Alexander Best , Dag-Erling Smorgrav Subject: Re: svn commit: r214431 - head/bin/rm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 07:55:46 -0000 On Thu, 28 Oct 2010 16:22:05 +1100 (EST) Bruce Evans wrote: > On Wed, 27 Oct 2010, Xin LI wrote: > > > 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. > > And that the underlying data storage us dumb. Any flash drive now > tries to minimise writes. It wouldn't take much buffering to defeat > the 0xff, 0,0xff pattern. Wear leveling should result in different > physical blocks being written each time if the writes get to the > lowest level of storage. > > And that block reallocation (done by ffs1 and ffs2) doesn't choose > different blocks. > > > 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. > > =============== > > Summary: it is very hard to tell whether -P works, even when you think > you know what all the subsystems are doing. > All this discussion leads me to the conclusion that we should just remove the -P functionality and add a remark to the man page that that was done because it isn't guaranteed to work on all file systems. Why give users a false sense of security? If they're concerned about data security then they should use geli or something similar. -- Gary Jennejohn