Date: Wed, 27 Oct 2010 22:42:57 +0000 From: Alexander Best <arundel@freebsd.org> To: d@delphij.net 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: <20101027224257.GB87087@freebsd.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 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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101027224257.GB87087>