All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: JP Abgrall <jpa@google.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
	linux-ext4@vger.kernel.org, Geremy Condra <gcondra@google.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] ext4: Add support for SFITRIM, an ioctl for secure FITRIM.
Date: Fri, 13 Jun 2014 15:07:03 +1000	[thread overview]
Message-ID: <20140613050703.GT4453@dastard> (raw)
In-Reply-To: <CAKP4w2QvVUNp18jnX69eP0hjA-T6zn2sT3TQ-P6zpu-EhXZPAQ@mail.gmail.com>

On Thu, Jun 12, 2014 at 09:37:58PM -0700, JP Abgrall wrote:
> On Thu, Jun 12, 2014 at 8:30 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Fri, Jun 13, 2014 at 01:15:38PM +1000, Dave Chinner wrote:
> >> Indeed, mixing -o discard and SFITRIM is a recipe for
> >> confusion and leakage - "but I used secure trim on the device!" -
> >> and so all discards either have to be secure or not.
> 
> The idea was to keep on not using -o discard. And move from FITRIM to SFITRIM.

IOWs, you want either normal discard or secure discard, and not a
mix of both. IOWs, you don't need SFITRIM, you need a "block device
does secure discard only" configuration flag...

> > Oh, and while I think of it secure discard at the filesystem level
> > isn't even a guarantee that you'll get rid of all stale references
> > to a sector - if the filesystem has freed and then re-allocated a
> > block without having gone through a discard cycle on that block,
> > then the underlying device may have old copies of the block that it
> > hasn't garbage collected and SFITRIM won't clean those up because it
> > won't ask to trim in-use blocks....
> 
> Arg. So, if understand this correctly, if the eMMC chip won't get a
> secure discard/trim of a block that gets reassigned to the FS, then
						      ^^ within

> data duplicates within the eMMC related to that block are not cleared,
> and the next SFITRIM won't even reach that block or the duplicates as
> the FS says they are in use.

Pretty much.

And even using -o discard is no guarantee that the filesystem will
issue a discard between freeing and re-using a block e.g.  XFS
explicitly avoids issuing discards for blocks it re-uses immediately
because they are always considered "in-use" from a transactional
POV. Hence there is no place where the block is considered free, and
hence there isn't a point in time where a discard can be safely
issued on that block.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2014-06-13  5:07 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13  2:14 [PATCH] ext4: Add support for SFITRIM, an ioctl for secure FITRIM JP Abgrall
2014-06-13  2:36 ` Darrick J. Wong
2014-06-13  2:57   ` JP Abgrall
2014-06-13  2:36 ` Eric Sandeen
2014-06-13  3:02   ` JP Abgrall
2014-06-13  3:12     ` Eric Sandeen
2014-06-13  3:19       ` JP Abgrall
2014-06-13  3:24         ` Eric Sandeen
2014-06-13  4:37           ` JP Abgrall
2014-06-13  3:15   ` Dave Chinner
2014-06-13  3:30     ` Dave Chinner
2014-06-13  4:37       ` JP Abgrall
2014-06-13  5:07         ` Dave Chinner [this message]
2014-06-13 14:20           ` Theodore Ts'o
2014-06-13 14:31             ` Theodore Ts'o
2014-06-13 19:44               ` JP Abgrall
2014-06-13 19:57                 ` Eric Sandeen
2014-06-13 20:12                   ` JP Abgrall
2014-06-13 23:41                 ` Theodore Ts'o
2014-06-14  0:46                   ` JP Abgrall
2014-06-17  2:49                   ` Dave Chinner
2014-06-17 11:27                     ` Theodore Ts'o
2014-06-17 11:55                     ` Lukáš Czerner
2014-06-17 12:46                       ` Theodore Ts'o
2014-06-17 13:00                         ` Lukáš Czerner
2014-06-17 13:54                           ` Theodore Ts'o
2014-06-17 17:53                             ` JP Abgrall
2014-06-18  9:33                               ` Lukáš Czerner
2014-06-18 21:51                                 ` JP Abgrall
2014-06-19  8:10                                   ` Lukáš Czerner
2014-06-18 22:06                                 ` Theodore Ts'o
2014-06-19  0:36                                   ` Dave Chinner
2014-06-19  8:15                                     ` Lukáš Czerner
2014-06-20  2:44                                       ` Martin K. Petersen
2014-06-19  8:33                                   ` Lukáš Czerner
2014-06-17 17:35                           ` JP Abgrall
2014-06-18  9:48 ` Lukáš Czerner

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=20140613050703.GT4453@dastard \
    --to=david@fromorbit.com \
    --cc=gcondra@google.com \
    --cc=jpa@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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.