Date:	Fri, 6 Aug 2010 15:49:53 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
cc:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
	jmoyer@...hat.com, rwheeler@...hat.com, eshishki@...hat.com,
	sandeen@...hat.com, jack@...e.cz, tytso@....edu
Subject: Re: [PATCH 0/3] Batched discard support

On Fri, 6 Aug 2010, Dmitry Monakhov wrote:

> Lukas Czerner <lczerner@...hat.com> writes:
> 
> > Hi, all
> >
> > because people were worried about possibly long stalls appearing
> > when FITRIM ioctl is working, I have changed the FITRIM interface
> > as Dimitry suggested. Now you can choose whether to trim whole
> > file system or just a part of it, resp. you can specify the range
> > of Bytes to trim.
> Agree with whole patch-set, except minor note for ext4'th path.
> Please feel free to add
> Reviewed-by: Dmitry Monakhov <dmonakhov@...nvz.org> to the series
> 
> The only thing what is still not obvious for me is that, there are
> several types of discard request possible
> 1) Simple discard 
> 2) Secure discard which was proposed here http://lkml.org/lkml/2010/6/24/71
> Should we specify which type should be used in ioctl flags?
> But i hope that we can just stick maximum security scenario
> Use secure discard if possible.

First of all, thanks for you review Dimitry. And second, to be honest I
am not entirely familiar with the Secure discard implementation. Right
now it just doing the simple discard like "send TRIM command", so it
does work just for devices which supports it. I suppose we can just
check blk_queue_discard() at some level and then decide whether to do
simple discard (TRIM), or secure discard "Write zeroes", when the device
does not support TRIM - if it is what you mean by secure discard.

Regards
-Lukas

> >
> > To be specific you can create something like this:
> >
> > int main(int argc, char **argv)
> > {
> > 	int fd;
> > 	uint64_t range[3];
> >
> > 	range[0] = 40960;
> > 	range[1] = 134217728;
> > 	range[2] = 4096;
> >
> > 	fd = open(argv[1], O_RDONLY);
> > 	if (fd < 0) {
> > 		perror("open");
> > 		return 1;
> > 	}
> >
> > 	if (ioctl(fd, FITRIM, range)) {
> > 		if (errno == EOPNOTSUPP)
> > 			fprintf(stderr, "FITRIM not supported\n");
> > 		else
> > 			perror("FITRIM");
> > 		return 1;
> > 	}
> >
> > 	return 0;
> > }
> >
> > Range items have following meaning:
> >
> > range[0] - (start) first Byte to trim
> > range[1] - (len) number of Bytes to trim from start
> > range[2] - (minlen) minimum extent length to trim, free extents shorter
> > than this number of Bytes will be ignored. This number will be rounded
> > up to the block size.
> >
> > So in my example it will trim all free extents from block 10 of first
> > alloc. group to block 10 of second alloc. group, assuming we have
> > block_size = 4096.
> >
> > Also, when you want to trim the whole fs, you can simply pass NULL
> > instead of range into the ioctl, or you can specify the range correctly
> > to cover the whole fs.
> >
> > Regards
> > -Lukas
> >
> > [PATCH 1/3] Add ioctl FITRIM.
> > [PATCH 2/3] Add batched discard support for ext3
> > [PATCH 3/3] Add batched discard support for ext4
> >
> >  fs/ext3/balloc.c        |  249 +++++++++++++++++++++++++++++++++++++++++++++++
> >  fs/ext3/super.c         |    1 +
> >  fs/ext4/ext4.h          |    2 +
> >  fs/ext4/mballoc.c       |  194 ++++++++++++++++++++++++++++++++++++
> >  fs/ext4/super.c         |    1 +
> >  fs/ioctl.c              |   34 +++++++
> >  include/linux/ext3_fs.h |    1 +
> >  include/linux/fs.h      |    2 +
> >  8 files changed, 484 insertions(+), 0 deletions(-)
> 

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists