From: Martin Steigerwald <Martin@lichtvoll.de>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
phillip@lougher.demon.co.uk, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Zero-clearing all zero-clearable bytes.
Date: Mon, 24 Nov 2008 15:56:10 +0100 [thread overview]
Message-ID: <200811241556.17213.Martin@lichtvoll.de> (raw)
In-Reply-To: <20081123112517.GB17607@khazad-dum.debian.net>
[-- Attachment #1: Type: text/plain, Size: 3500 bytes --]
Hi!
Am Sonntag 23 November 2008 schrieben Sie:
> On Sun, 23 Nov 2008, Tetsuo Handa wrote:
> > What I wanted to do is "Zero-clearing *all zero-clearable* bytes".
> Other than acessing the fs directly with something fs-specific that
> knows how to do it, the following trick comes to mind:
>
> 1. compress all files to a tar.bz2.
> 2. remove all files
> 3. zero fs using dd to a file (will zero all blocks except for the ones
> used by the tar.bz2
> 4. unpack tar.bz2
> 5. remove tar.bz2
> 6. redo the dd trick. This will now zero all blocks that were in use by
> the tar.bz2.
>
> Of course, this only works if the (kernel, glibc, tar) are not writing
> random junk to the unused parts of a fs block.
>
> The cost is from 1 to 3 rm'ed inodes left behind. If you use two
> filesystems (i.e. tar to outside the filesystem), you avoid that
> possibility.
>
> > I wished there is a utility to zero-fill such bytes.
>
> So do I. And a IOCTL/syscall/whatever that we could use to sanitize
> (i.e. fill with an user-supplied byte) half-used blocks, so that we
> could have it on the most used filesystems (ext2, ext3, xfs,
> reiser...), and that we could implement scrub-erasing of unused
> filesystem areas properly.
There are at least 2 tools - I think there was even another one. I did not
test them and do not know whether they work on singular inode basis.
Debian Package zerofree:
Description: zero free blocks from ext2/3 file-systems
Zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3
file-system and fills them with zeroes. This is useful if the device
on which this file-system resides is a disk image. In this case,
depending on the type of disk image, a secondary utility may be able
to reduce the size of the disk image after zerofree has been
run. Zerofree requires the file-system to be unmounted or mounted
read-only.
.
The usual way to achieve the same result (zeroing the unallocated
blocks) is to run "dd" do create a file full of zeroes that takes up
the entire free space on the drive, and then delete this file. This
has many disadvantages, which zerofree alleviates:
* it is slow;
* it makes the disk image (temporarily) grow to its maximal extent;
* it (temporarily) uses all free space on the disk, so other
concurrent write actions may fail.
.
Zerofree has been written to be run from GNU/Linux systems installed
as guest OSes inside a virtual machine. If this is not your case, you
almost certainly don't need this package.
Debian Package wipe2fs:
Package: wipe2fs
Priority: extra
Section: admin
Installed-Size: 112
Maintainer: Martin A. Godisch <godisch@debian.org>
Architecture: i386
Version: 0.2.1-1
Depends: e2fslibs, libc6 (>= 2.7-1), libcomerr2 (>= 1.33-3)
Filename: pool/main/w/wipe2fs/wipe2fs_0.2.1-1_i386.deb
Size: 14150
MD5sum: da0c0d4319fda08a1f5fc7a92f5b2535
SHA1: 2f7d55fbfda34b328b67f17e5e2e26d8f853bdac
SHA256: 569bc452331b1067f49ba5aaf36dd7bb357036307b79156c4d7c5beaa2a17545
Description: Securely wipe unused space in ext2/3 filesystems
This users-pace program locates unused space in ext2/3 filesystems
and overwrites the space with zero. wipe2fs also reaches the slack
space at the end of files, it does not require kernel filesystem
support.
Homepage: http://web.cecs.pdx.edu/~cklin/wipe2fs/
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-11-24 15:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-22 3:36 Zero-clearing all zero-clearable bytes Tetsuo Handa
2008-11-22 17:44 ` Andreas Dilger
2008-11-23 0:15 ` Tetsuo Handa
2008-11-23 3:05 ` Phillip Lougher
2008-11-23 4:27 ` Phillip Lougher
2008-11-23 5:03 ` Tetsuo Handa
2008-11-23 11:25 ` Henrique de Moraes Holschuh
2008-11-24 14:56 ` Martin Steigerwald [this message]
2008-11-25 10:59 ` Tetsuo Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811241556.17213.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=hmh@hmh.eng.br \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=phillip@lougher.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.