lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Aug 2011 02:16:14 -0600
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Ric Wheeler <ricwheeler@...il.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-ext4@...r.kernel.org
Subject: Re: Feature request: e2fsck -z

On 2011-08-10, at 12:34 AM, Ric Wheeler wrote:
> On 08/09/2011 06:52 PM, H. Peter Anvin wrote:
>> Hi all,
>> 
>> This is something I've wanted to see for a very long time, and it
>> finally occurred to me that perhaps I should say something about it!
>> 
>> It would be a very nice thing to have a flag to e2fsck, presumably -z,
>> to zero out any unused data blocks, inodes and so on.  The goal is to
>> minimize the amount of space required after compressing a virtual disk
>> image or similar, and to make sure any non-data isn't lying around.
> 
> Do you need it to be in the fsck tool?
> 
> If you have a sparsely allocated block map under your file system, doing a zero of all blocks could add hours for a big, slow S-ATA drives (2-3 hours for a 1TB drive).

I think Ted has a tool that does this already.  It should be relatively simple oo do, like "dd if=/dev/zero of=/mountpoint/temp_zero_file && rm /mountpoint/temp_zero_file.

> An alternative for SSD's and devices that do TRIM/UNMAP would be to use one of the batched discard tools (that would make discarded data read back as zeroed).

In fact, I thought Lukas has already made a tool for sending BLKDISCARD for all unused parts of the filesystem?

Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ