-----BEGIN PGP SIGNED MESSAGE-----
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
>>> i'm not a fs expert, but i think mentioning that -P won't work for COW fs
>> 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:
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.
Xin LI <email@example.com> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
-----END PGP SIGNATURE-----