[Top] [All Lists]

Re: [PATCH] mkfs: add discard support

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] mkfs: add discard support
From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Sat, 10 Oct 2009 06:22:24 +0200
Cc: Andi Kleen <andi@xxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20091009023022.GL9464@xxxxxxxxxxxxxxxx>
References: <20091006184758.GA4780@xxxxxxxxxxxxx> <20091007044215.GK9464@xxxxxxxxxxxxxxxx> <87iqerymu0.fsf@xxxxxxxxxxxxxxxxx> <20091009023022.GL9464@xxxxxxxxxxxxxxxx>
User-agent: Mutt/
On Fri, Oct 09, 2009 at 01:30:22PM +1100, Dave Chinner wrote:
> On Wed, Oct 07, 2009 at 10:24:07PM +0200, Andi Kleen wrote:
> > Dave Chinner <david@xxxxxxxxxxxxx> writes:
> > > On Tue, Oct 06, 2009 at 02:47:58PM -0400, Christoph Hellwig wrote:
> > >> Call the BLKDISCARD ioctl to mark the whole disk as unused before 
> > >> creating
> > >> a new filesystem.  This will allow SSDs, Arrays with thin provisioning 
> > >> support
> > >> and virtual machines to make smarter allocation decisions.
> > >
> > > Good idea, but perhaps the discard should be optional rather than
> > > unconditional.  My immediate thought was the SOP for setting up
> > > encrypted devices - fill the empty disk with random data before
> > > setting up the encrypted device. If you then send it a discard....
> >
> > This actually doesn't really work for SSDs, because SSDs typically
> > have more internal capacity than they advertise and when you fill
> > it up then it will just allocate new blocks and leave some of the
> > blocks with the existing data around.
> Agreed, but initialisation with random data before encryption is not
> to delete existing information on the drive - it is to prevent
> simple side-channel attacks that can significantly reduce the
> strength of the encryption (e.g. an observer can tell the difference

I see. That makes sense.

Although to be pedantic your description above is slightly
wrong then -- you need to fill it up after setting up the encryption,
not before. In this case it might be actually more reasonable
to simply fill the file system with a random file (although on XFS
might need to reset inode limits first to catch the metadata

ak@xxxxxxxxxxxxxxx -- Speaking for myself only.

<Prev in Thread] Current Thread [Next in Thread>