On Tue, 17 Jun 2014, Dave Chinner wrote: > Date: Tue, 17 Jun 2014 12:49:53 +1000 > From: Dave Chinner <david@xxxxxxxxxxxxx> > To: Theodore Ts'o <tytso@xxxxxxx> > Cc: JP Abgrall <jpa@xxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>, > linux-ext4@xxxxxxxxxxxxxxx, Geremy Condra <gcondra@xxxxxxxxxx>, > "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH] ext4: Add support for SFITRIM, > an ioctl for secure FITRIM. > > On Fri, Jun 13, 2014 at 07:41:34PM -0400, Theodore Ts'o wrote: > > On Fri, Jun 13, 2014 at 12:44:34PM -0700, JP Abgrall wrote: > > > The per-file secure discard seems to be the way to go, as there are > > > only a few places in Android where this needs to be turned on. > > > The current idletime-fstrim would switch from FITRIM to SFITRIM to > > > reduce the leftovers. > > > > OK, how about this? The following patch is in the Google data center > > kernel, but I never got around to get it upstream (oops, was on my > > todo list, but it never happened). > > > > If you want to adopt this for usptream, and add support for > > BLKSECDISCARD as well as BLKDISCARD, then you could for each file that > > you want to do the per-file secure discard, you would just have to > > open the file, call the BLKSECDISCARD ioctl, and then delete the file. > > > > Cheers, > > > > - Ted > > > > commit 16ff6352b123aa134417793d636f05cd4e240eaa > > Author: Theodore Ts'o <tytso@xxxxxxxxxx> > > Date: Fri Dec 20 12:48:26 2013 -0500 > > > > ext4: add support for the BLKDISCARD ioctl > > > > The blkdicard ioctl previously only worked on block devices. Allow > > this ioctl to work on ext4 files. > > > > This commit is intended to be sent upstream. > > Not in that form - it's an ugly API hack. > > This is really just an extension of hole punching (if the blocks in > the file are being removed) or zeroing (if the blocks are being > retained by the file). Either way, fallocate() is the interface > used for per-file block level manipulations, and either of these > operations could issue a discard (secure or not) during the > punch/zero operation.... I definitely agree with Dave here it is an ugly API hack. Fallocate seems much more suitable for this. New flag FALLOC_FL_ISSUE_DISCARD which would work with FALLOC_FL_PUNCH_HOLE, FALLOC_FL_ZERO_RANGE and possibly FALLOC_FL_COLLAPSE_RANGE might actually be useful. -Lukas > > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html