On Thu, 28 Oct 2010 14:11:14 -0700
Garrett Cooper gcoo...@freebsd.org wrote:
Unfortunately it's implied superficially by the 3 pass tort; but as
most people who understand magnetic disks know, unless you completely
obliterate a disk, wipe over it with random data enough times,
whatever, the
On Fri, 29 Oct 2010, Bruce Cran wrote:
On Thu, 28 Oct 2010 14:11:14 -0700 Garrett Cooper gcoo...@freebsd.org
wrote:
Unfortunately it's implied superficially by the 3 pass tort; but as most
people who understand magnetic disks know, unless you completely obliterate
a disk, wipe over it with
Quoting Garrett Cooper gcoo...@freebsd.org (from Thu, 28 Oct 2010
14:11:14 -0700):
Unfortunately it's implied superficially by the 3 pass tort; but as
most people who understand magnetic disks know, unless you completely
obliterate a disk, wipe over it with random data enough times,
whatever,
On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans b...@optusnet.com.au wrote:
On Wed, 27 Oct 2010, Xin LI wrote:
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,
On Thu, Oct 28, 2010 at 09:55:38AM +0200, Gary Jennejohn wrote:
On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans b...@optusnet.com.au wrote:
On Wed, 27 Oct 2010, Xin LI wrote:
I think what really defeats -P is the fact that the file system or
underlying data storage would not
On Thu Oct 28 10, Gary Jennejohn wrote:
On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans b...@optusnet.com.au wrote:
On Wed, 27 Oct 2010, Xin LI wrote:
I think what really defeats -P is the fact that the file system or
underlying data storage would not overwrite data on a file
On Thu, Oct 28, 2010 at 10:25:47AM +, Alexander Best wrote:
On Thu Oct 28 10, Gary Jennejohn wrote:
On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans b...@optusnet.com.au wrote:
On Wed, 27 Oct 2010, Xin LI wrote:
I think what really defeats -P is the fact that the file
On Thu Oct 28 10, Ceri Davies wrote:
On Thu, Oct 28, 2010 at 10:25:47AM +, Alexander Best wrote:
On Thu Oct 28 10, Gary Jennejohn wrote:
On Thu, 28 Oct 2010 16:22:05 +1100 (EST)
Bruce Evans b...@optusnet.com.au wrote:
On Wed, 27 Oct 2010, Xin LI wrote:
I think what
On Thu, 28 Oct 2010, Gary Jennejohn wrote:
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
On Thu Oct 28 10, Robert Watson wrote:
On Thu, 28 Oct 2010, Gary Jennejohn wrote:
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,
On Thu, 28 Oct 2010, Alexander Best wrote:
For example, you could imagine a pathconf() call that asks the file system
if overwriting a file is likely to result in the data going away -- UFS
could answer yes unless it's snapshotting the file system, and ZFS could
simply answer no.
In
On Wed Oct 27 10, Dag-Erling Smorgrav wrote:
Author: des
Date: Wed Oct 27 18:48:23 2010
New Revision: 214431
URL: http://svn.freebsd.org/changeset/base/214431
Log:
Language cleanup.
Modified:
head/bin/rm/rm.1
Modified: head/bin/rm/rm.1
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
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
On Wed, Oct 27, 2010 at 14:48, Alexander Best arun...@freebsd.org wrote:
On Wed Oct 27 10, Doug Barton wrote:
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
-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
On Wed Oct 27 10, Juli Mallett wrote:
On Wed, Oct 27, 2010 at 14:48, Alexander Best arun...@freebsd.org wrote:
On Wed Oct 27 10, Doug Barton wrote:
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
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
On Wed, Oct 27, 2010 at 03:33:01PM -0700, Xin LI wrote:
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,
On Wed, 27 Oct 2010, Xin LI wrote:
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
20 matches
Mail list logo
