On Thu, 28 Oct 2010, Gary Jennejohn wrote:
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.
I'm not sure I entirely agree with this conclusion: there are times when -P
can be quite effective at removing data from a system, and not having it
available when it could work might also be problematic.
Part of the problem here is that we have successfully abstracted away a lot of
information going up the storage stack. One possibly solution to this problem
is to add ways for that information to propagate better -- in the same way
that the end-to-end argument in network design is moderated by the reality
that performance can be dramatically improved if information gathering can be
done with an awareness of lower layers (for example, PMTU discovery), even if
decisions about how to use that information are at the endpoints only.
For example, you could imagine a pathconf() call that asks the file system if
overwriting a file is likely to result in the data going away -- UFS could
answer "yes" unless it's snapshotting the file system, and ZFS could simply
answer "no".
In FreeBSD 9, we're going to have two common file system configurations: ZFS
and UFS+SUJ; the latter will do overwriting of files just fine on most current
media.
Robert
_______________________________________________
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"
