Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Oct 2010 10:25:47 +0000
From:      Alexander Best <arundel@freebsd.org>
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, Dag-Erling Smorgrav <des@FreeBSD.org>
Subject:   Re: svn commit: r214431 - head/bin/rm
Message-ID:  <20101028102547.GA56817@freebsd.org>
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
On Thu Oct 28 10, Gary Jennejohn wrote:
> On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
> Bruce Evans <brde@optusnet.com.au> 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.

that might be the ultimate solution. also one could use security/srm instead.

+1 here. ;)

question is: should -P be removed entirely or be made a no op?

cheers.
alex

> 
> --
> Gary Jennejohn

-- 
a13x



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101028102547.GA56817>