From: David Sterba <dsterba@suse.cz>
To: Gareth Pye <gareth@cerberos.id.au>
Cc: Chris Mason <chris.mason@fusionio.com>, Kyle <lists@lolwut.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Impossible or Possible to Securely Erase File on Btrfs?
Date: Tue, 19 Mar 2013 10:19:56 +0100 [thread overview]
Message-ID: <20130319091956.GR7229@twin.jikos.cz> (raw)
In-Reply-To: <CA+WRLO_09TLuoJ4QEzudrNxksJUYsktTRqgYX3=GR2O3989oCw@mail.gmail.com>
On Tue, Mar 19, 2013 at 09:48:56AM +1100, Gareth Pye wrote:
> Would it make sense for btrfs to support a write zeros to empty space
> erase? I know it would be slow as it would have to write to all the
> free space in the file system but it would be useful.
>
> It's probably pretty far down the priority list for development though I expect.
I have prototyped this some time ago
http://repo.or.cz/w/linux-2.6/btrfs-unstable.git/commit/55ec5c00022be8f2bbed06b99b5f4be5832a5451
It reuses the trim code that already traverses the free space but calls
blkdev_issue_zeroout instead. The overwrite pattern could be extended to
random data, some posion patterns (like leaf that has 0 items and could
be recognized in the code to catch misdirected writes; similarly for
tree node blocks), or the secure discard.
(I haven't resolved what to do if there's a mixture of HDDs and SSDs,
rewriting the free space has different impact on the underlying
devices.)
The existing FITRIM ioctl structure fstrim_range does not contain any
spare bytes so either we need to go with own ioctl or propose FITRIM_V2.
david
next prev parent reply other threads:[~2013-03-19 9:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-18 18:15 Impossible or Possible to Securely Erase File on Btrfs? Kyle
2013-03-18 18:57 ` Hugo Mills
2013-03-18 19:09 ` Chris Murphy
2013-03-18 23:00 ` Kyle
2013-03-19 4:41 ` Chris Murphy
2013-03-18 19:18 ` Chris Mason
2013-03-18 22:48 ` Gareth Pye
2013-03-19 9:19 ` David Sterba [this message]
2013-03-19 3:18 ` Chris Murphy
2013-03-19 9:06 ` David Sterba
2013-03-20 0:52 ` Chris Murphy
2013-03-19 22:46 ` Marek Otahal
2013-03-20 19:20 ` Martin Steigerwald
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=20130319091956.GR7229@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=chris.mason@fusionio.com \
--cc=gareth@cerberos.id.au \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@lolwut.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox