linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Czerner <lczerner@redhat.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Lukas Czerner <lczerner@redhat.com>,
	linux-ext4@vger.kernel.org, jmoyer@redhat.com,
	rwheeler@redhat.com, eshishki@redhat.com, sandeen@redhat.com,
	jack@suse.cz, tytso@mit.edu
Subject: Re: [PATCH 0/3] Batched discard support
Date: Fri, 6 Aug 2010 15:49:53 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1008061539010.3645@localhost> (raw)
In-Reply-To: <87zkwzriwm.fsf@dmon-lap.sw.ru>

On Fri, 6 Aug 2010, Dmitry Monakhov wrote:

> Lukas Czerner <lczerner@redhat.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@openvz.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(-)
> 

-- 

  reply	other threads:[~2010-08-06 13:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-06 11:31 [PATCH 0/3] Batched discard support Lukas Czerner
2010-08-06 11:31 ` [PATCH 1/3] Add ioctl FITRIM Lukas Czerner
2010-08-06 11:31 ` [PATCH 2/3] Add batched discard support for ext3 Lukas Czerner
2010-08-06 11:31 ` [PATCH 3/3] Add batched discard support for ext4 Lukas Czerner
2010-08-06 13:03   ` Dmitry Monakhov
2010-08-06 13:23     ` Lukas Czerner
2010-08-07 22:25   ` Jan Kara
2010-08-10 11:32     ` Lukas Czerner
2010-08-06 13:05 ` [PATCH 0/3] Batched discard support Dmitry Monakhov
2010-08-06 13:49   ` Lukas Czerner [this message]
2010-08-06 14:24     ` Dmitry Monakhov
2010-08-06 14:32     ` Lukas Czerner
2010-08-06 15:02       ` Dmitry Monakhov
2010-08-10 11:31         ` Lukas 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=alpine.LFD.2.00.1008061539010.3645@localhost \
    --to=lczerner@redhat.com \
    --cc=dmonakhov@openvz.org \
    --cc=eshishki@redhat.com \
    --cc=jack@suse.cz \
    --cc=jmoyer@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=rwheeler@redhat.com \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).