svn commit: r214431 - head/bin/rm

Gary Jennejohn gljennjohn at googlemail.com
Thu Oct 28 07:55:46 UTC 2010


On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans <brde at 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.

--
Gary Jennejohn


More information about the svn-src-all mailing list