Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Oct 2010 15:33:01 -0700
From:      Xin LI <delphij@delphij.net>
To:        Alexander Best <arundel@FreeBSD.ORG>
Cc:        svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, Doug Barton <dougb@FreeBSD.ORG>, src-committers@FreeBSD.ORG, Dag-Erling Smorgrav <des@FreeBSD.ORG>
Subject:   Re: svn commit: r214431 - head/bin/rm
Message-ID:  <4CC8A89D.5070909@delphij.net>
In-Reply-To: <20101027214822.GA82697@freebsd.org>
References:  <201010271848.o9RImNSR019344@svn.freebsd.org> <20101027212601.GA78062@freebsd.org> <4CC899C3.7040107@FreeBSD.org> <20101027214822.GA82697@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/27/10 14:48, Alexander Best wrote:
> On Wed Oct 27 10, Doug Barton wrote:
>> On 10/27/10 14:26, Alexander Best wrote:
>>> are in fact COW fs the only exception where the -P flag won't work? before
>>> r213582 LFS was mentioned here and that the block size must be fixed.
>>> also the comment in rm.c says that -P won't work for any logging file 
>>> systems.
>>> i'm not a fs expert, but i think mentioning that -P won't work for COW fs 
>>> isn't
>>> enough.
>>
>> What may be a better approach is to confirm the fs' that DO work, list 
>> them, and then add something to the effect of, "This feature is unlikely 
>> to work on other file systems."
> 
> i don't think that's a good approach, because then the rm(1) has to be changed
> everytime freebsd gets a new fs which works with the -P option. i think it's
> better to list which fs semantics DON'T work. so if freebsd gets a new fs,
> users simply have to know which semantics the new fs is based on and can decide
> for themselves whether the -P switch will work or not.
> 
> so far the -P option doesn't seem to work for:
> 
> - COW fs and/or
> - fs with a variable block size and/or
> - fs which do journaling
> 
> please correct me if i got anything wrong. so i think having such a list in the
> rm(1) manual would be very nice (maybe improving the comment in rm.c too).

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.

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.
===============

Cheers,
- -- 
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!	       Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMyKicAAoJEATO+BI/yjfBElYIAMP70g1a+YheuKD14NXugVTU
sG4KEWAjRSZCe808f46AXU+wJePnRFkYVKD+A+6aH63y/r2V0e3CVMUYZZXr4l/d
HJRnZjJK9e/YJv8pcCpq7PgnmPzMa4m4BQNYVJoNGbPd75V27wMi3hgBzzPrJxWL
aBuB31hpU32PcpvzQgBPLiNzjEuLRq5be42HjgTPT1qGwSMEQcLgXOfG9l6TS27s
I5n5KPU7dEFt0Z+3ljQM+F3Fk2wmy/EOAeRcZL89xvFZIAYmtVrL3UcniHALPRSn
CAbGrNpCbvh2RZvJX1Cwu3H+PVIlIcl2uG/aiOEC7m/tA29LfPPXG0IzUN9qVLc=
=LQen
-----END PGP SIGNATURE-----



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