Date: Thu, 28 Oct 2010 09:30:40 +0100 From: Ceri Davies <ceri@submonkey.net> To: Gary Jennejohn <gljennjohn@googlemail.com> Cc: Doug Barton <dougb@FreeBSD.org>, d@delphij.net, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@FreeBSD.org, Alexander Best <arundel@FreeBSD.org>, Dag-Erling Smorgrav <des@FreeBSD.org> Subject: Re: svn commit: r214431 - head/bin/rm Message-ID: <20101028083040.GA5488@submonkey.net> In-Reply-To: <20101028095538.24147119@ernst.jennejohn.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> <20101028095538.24147119@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2010 at 09:55:38AM +0200, Gary Jennejohn wrote: > On Thu, 28 Oct 2010 16:22:05 +1100 (EST) > Bruce Evans <brde@optusnet.com.au> 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 not > > > guaranteed. FS with variable block size - I believe this really depe= nds > > > 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. > >=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 Engl= ish > > > 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 blo= ck > > > when data is written on existing offset. Several factors including t= he > > > 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. > > > =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. I was about to suggest the same thing. Sounds like -P requires far too many ducks to be lined up in order to work. Ceri --=20 Haffely, Gaffely, Gaffely, Gonward. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFMyTSvocfcwTS3JF8RAn69AJ9GRZnT5EdnwaDyu2juqGFRZPH2AACgiinY H+lZcVTTdV/QDr5e846LoM4= =gdId -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101028083040.GA5488>