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>