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.
Bruce
_______________________________________________
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"
