svn commit: r214431 - head/bin/rm

[Alexander Best]

On Wed Oct 27 10, Xin LI wrote:
> -----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.
> ===============

personally i like this approach a lot better than listing all working fs,
because that list would be quite long since e.g. for UFS2 (as you mentioned)
one cannot asume that it will support the -P option at all times.

cheers.
alex

> 
> Cheers,
> - -- 
> Xin LI <delphij at 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-----

-- 
a13x