All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Wheeler <ricwheeler@gmail.com>
To: Andreas Dilger <adilger@whamcloud.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-ext4@vger.kernel.org
Subject: Re: Feature request: e2fsck -z
Date: Wed, 10 Aug 2011 09:22:40 +0100	[thread overview]
Message-ID: <4E423FD0.40108@gmail.com> (raw)
In-Reply-To: <4420E0D8-5E16-4FD0-A7A9-B462F02D742D@dilger.ca>

On 08/10/2011 09:16 AM, Andreas Dilger wrote:
> 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.

This will work but will be a potential multi-hour long process (and cause out of 
space errors at some point for other applications for a very brief window :))

>
>> 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

Right, I think he has. That tool (not part of fsck) would do the job much 
quicker for enabled devices,

Ric


  reply	other threads:[~2011-08-10  8:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-09 17:52 Feature request: e2fsck -z H. Peter Anvin
2011-08-10  6:34 ` Ric Wheeler
2011-08-10  8:16   ` Andreas Dilger
2011-08-10  8:22     ` Ric Wheeler [this message]
2011-08-10  9:35       ` Lukas Czerner
2011-08-10 10:55         ` Florian Weimer
2011-08-10 11:01           ` Lukas Czerner
2011-08-10 11:04             ` Florian Weimer
2011-08-10 11:06               ` Ric Wheeler
2011-08-10 11:09               ` Lukas Czerner
2011-08-10 13:25   ` Ted Ts'o
2011-08-10 14:34     ` Lukas Czerner
2011-08-10  7:54 ` Ron Yorston

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=4E423FD0.40108@gmail.com \
    --to=ricwheeler@gmail.com \
    --cc=adilger@whamcloud.com \
    --cc=hpa@zytor.com \
    --cc=linux-ext4@vger.kernel.org \
    /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.