From owner-svn-src-all@FreeBSD.ORG Thu Oct 28 10:37:34 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 54382106566B; Thu, 28 Oct 2010 10:37:34 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from scuttle.submonkey.net (scuttle.submonkey.net [208.111.43.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA6D8FC19; Thu, 28 Oct 2010 10:37:33 +0000 (UTC) Received: from cpc6-cdif11-2-0-cust58.5-1.cable.virginmedia.com ([62.255.146.59] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBPrL-0000n0-SR; Thu, 28 Oct 2010 10:37:28 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PBPrJ-0003M3-CP; Thu, 28 Oct 2010 11:37:25 +0100 Date: Thu, 28 Oct 2010 11:37:25 +0100 From: Ceri Davies To: Alexander Best Message-ID: <20101028103725.GC5488@submonkey.net> 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> <20101028095538.24147119@ernst.jennejohn.org> <20101028102547.GA56817@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <20101028102547.GA56817@freebsd.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ceri Davies Cc: Doug Barton , d@delphij.net, svn-src-all@FreeBSD.org, Gary Jennejohn , src-committers@FreeBSD.org, Bruce Evans , svn-src-head@FreeBSD.org, 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 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 10:37:34 -0000 --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2010 at 10:25:47AM +0000, Alexander Best wrote: > On Thu Oct 28 10, Gary Jennejohn wrote: > > On Thu, 28 Oct 2010 16:22:05 +1100 (EST) > > Bruce Evans wrote: > >=20 > > > On Wed, 27 Oct 2010, Xin LI wrote: > > >=20 > > > > 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 n= ot > > > > guaranteed. FS with variable block size - I believe this really de= pends > > > > on the implementation. > > > > > > > > If I understood the code correctly, UFS, UFS+SU, UFS+SUJ, msdosfs a= nd > > > > 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. > > >=20 > > > 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. > > >=20 > > > And that block reallocation (done by ffs1 and ffs2) doesn't choose > > > different blocks. > > >=20 > > > > It seems to be hard for me to conclude all cases in short, plain En= glish > > > > but I'm all for improvements to the manual page to describe that in= an > > > > elegant and precise manner. > > > > > > > > Maybe something like: > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > BUGS > > > > > > > > The -P option assumes that the underlying storage overwrites file b= lock > > > > 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 fil= es > > > > are overwritten, other types of files are not. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > Summary: it is very hard to tell whether -P works, even when you think > > > you know what all the subsystems are doing. > > >=20 > >=20 > > 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. > >=20 > > Why give users a false sense of security? If they're concerned about > > data security then they should use geli or something similar. >=20 > that might be the ultimate solution. also one could use security/srm inst= ead. >=20 > +1 here. ;) >=20 > question is: should -P be removed entirely or be made a no op? Probably best that it fail. Ceri --=20 Haffely, Gaffely, Gaffely, Gonward. --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFMyVJlocfcwTS3JF8RAjW4AJ41Ld0fBOrTS2f+FXDgcQKwfEhI3QCgq5a4 3G0STMIOJJwW2RudigPfA3o= =7vl4 -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT--