On Sat, Nov 09, 2002 at 01:42:13PM -0500, Skylar Thompson wrote: > 3. you're wiping a file in a log structured file system or > any FS that doesn't overwrite the file's previously allocated > sectors or the drive has reassigned one or more sectors due to error > > I'm not an expert on filesystems, but "log structured file system" sounds > like a journaled filesystem, so I'm not confident that wipe will work on > Ext3. Another utility for deleting securely, shred, says that it is very > difficult to delete securely on a journaled filesystem. Nope, a log structured filesystem is very different from a journalled update-in-place filesystem. A log structured filesystem is one where you never overwrite an existing block, but always write a new block. This means that when you modify a block, you need to write a new block on the log, followed by a new inode which points to the new block, followed by a new directory entry which points at the new inode, followed by a new parent directory, etc. all the way up to the root. As a result, file fragmentation very quickly takes over, and so log structured filesystems generally only win if (a) you have huge amounts of memory so that everything you care about is in cache, so the fact that files are fragmented over hell-and-gone isn't an issue, and (b) you have vast amounts of disk space, so that you don't need to stop and run the filesystem cleaner when the circular log which comprises the filesystem has eaten all available disk space (remember, a log structured filesystem is constantly rewriting directory blocks whenever it needs to modify a data block, so in particular there will be many, many, many copies of different versions of the root directory are constantly into the log structured filesystem.) For this reason, log structured filesystems have in practice turned out to be performance disasters, and while there was a log-structured filesystem included as part of BSD 4.4, it was never used in any kind of production fashion. The newly released Reiserfs4 claims to be a log-structured filesystem, and Hans Reisers has claimed some impressive benchmark numbers (4 times as fast as ext2). However, I'm skeptical of these results, because (a) it was only on a untar and tar of the kernel sources; with no measurement of how the filesystem performance might degrade over time, and (b) Hans mentioned that the tar file had to have its files written in a hash sort order so that when the files were unpacked onto disk, they could be read again for the packing part of the benchmark without needing any disk seeks. (Can you say, "Rigged demo"?) Anyway, I digresss...... in any case, this is quite different from ext3, which is an update-in-place filesystem (as distinguished from a log-structured filesystem) that uses a journal to guarantee consistency. So most of the time wiper programs will work with ext3, as long as you don't have data journalling enabled. If you do, then there may be copies of the data blocks on the journal. They will eventually get overwritten, since the journal is (relatively small) circular buffer. So if the journal is 16 MB, and you have data journalling enabled, simply writing 64MB of data will guarantee that the blocks on the journal will have been overwritten 4 times. Normally, however, data journalling is not enabled; it is not the default mode used by the ext3 filesystem. So this situation would not arise in most cases. - Ted _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
