Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Oct 2010 16:22:05 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        d@delphij.net
Cc:        Doug Barton <dougb@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-head@FreeBSD.org, Alexander Best <arundel@FreeBSD.org>, Dag-Erling Smorgrav <des@FreeBSD.org>
Subject:   Re: svn commit: r214431 - head/bin/rm
Message-ID:  <20101028152418.A916@besplex.bde.org>
In-Reply-To: <4CC8A89D.5070909@delphij.net>
References:  <201010271848.o9RImNSR019344@svn.freebsd.org> <20101027212601.GA78062@freebsd.org> <4CC899C3.7040107@FreeBSD.org> <20101027214822.GA82697@freebsd.org> <4CC8A89D.5070909@delphij.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



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