On Thu, 28 Oct 2010 16:22:05 +1100 (EST) Bruce Evans <b...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
