Greetings all,
I am curious if anyone knows why utilities such as
'GNU shred' (part of coreutils) and 'wipe' say they
are not effective on journalled file systems-
especially EXT3.
Is it because you can't "guarantee" that the journal
has been flushed/wiped (i.e. you have the journal
'between' you and the actual data blocks on the
physical disk), or because of buffering, or some other
reason?
On the same note, does anyone know of any utility that
does overwrite EXT3? Most specifically, I am Looking
for an open source utility that will do a
MULTIPLE-pass overwrite of any data blocks used by a
file. (This is for a government related project and
DOD says it's not sufficient to just do a single
overwrite of all zero's).
Any help/pointers are greatly appreciated. Thanks.
Below is an excerpt from the shred man page which
specifically mentions EXT3:
----
CAUTION: Note that shred relies on a very important
assumption: that the filesystem overwrites data in
place. This is the traditional way to do things, but
many modern filesystem designs do not satisfy this
assumption. The following are examples of filesystems
on which shred is not effective:
* log-structured or journaled filesystems, such as
those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3,
etc.)
----
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Andreas Dilger
2004-Oct-13 07:26 UTC
Multiple-pass overwrite of EXT3 file on a journalled fs
On Oct 08, 2004 15:18 -0700, sp0ck1701 wrote:> I am curious if anyone knows why utilities such as > 'GNU shred' (part of coreutils) and 'wipe' say they > are not effective on journalled file systems- > especially EXT3. > > Below is an excerpt from the shred man page which > specifically mentions EXT3: > > ---- > CAUTION: Note that shred relies on a very important > assumption: that the filesystem overwrites data in > place. This is the traditional way to do things, but > many modern filesystem designs do not satisfy this > assumption. The following are examples of filesystems > on which shred is not effective: > > * log-structured or journaled filesystems, such as > those supplied with > > AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, > etc.) > ----I don't know why they would say this. With very early versions of ext3 (or filesystems mounted with data=journal) all data writes would also go to the journal, so you would get two copies of your data on disk. The "shred" overwrite would in theory only erase the copy in the filesystem. It is also possible to get a copy of the last partial page of a truncated file being put into the journal. Of course, this neglects the fact that the journal is continually being overwritten so the only time there might be data in the journal (in the non-default data=journal mode) is after it was just written to disk. In normal filesystem usage this would be overwritten hundreds of times, and the user-space overwriting tool would itself cause the journal to be overwritten in this case (taking relative sizes of files and journal into account). I know reiser4 on the other hand is a log-structured filesystem, so overwriting a file has no guarantee that even the data blocks will be overwritten. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://listman.redhat.com/archives/ext3-users/attachments/20041013/da59ef45/attachment.sig>