linux-ext4 - Re: [PATCH 1/3] Add ioctl FITRIM.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Aug 2010 10:36:47 +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 1/3] Add ioctl FITRIM.

On Thu, 5 Aug 2010, Dmitry Monakhov wrote:

> Lukas Czerner <lczerner@...hat.com> writes:
> 
> > On Wed, 4 Aug 2010, Dmitry Monakhov wrote:
> >
> >> Lukas Czerner <lczerner@...hat.com> writes:
> >> 
> >> > Adds an filesystem independent ioctl to allow implementation of file
> >> > system batched discard support.
> >> >
> >> > Signed-off-by: Lukas Czerner <lczerner@...hat.com>
> >> > ---
> >> >  fs/ioctl.c         |   31 +++++++++++++++++++++++++++++++
> >> >  include/linux/fs.h |    2 ++
> >> >  2 files changed, 33 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/fs/ioctl.c b/fs/ioctl.c
> >> > index 2d140a7..6c01c3c 100644
> >> > --- a/fs/ioctl.c
> >> > +++ b/fs/ioctl.c
> >> > @@ -540,6 +540,33 @@ static int ioctl_fsthaw(struct file *filp)
> >> >  	return thaw_super(sb);
> >> >  }
> >> >  
> >> > +static int ioctl_fstrim(struct file *filp, unsigned long arg)
> >> BTW why do we have to trim fs in one shot ?
> >> IMHO it is much suitable to provide start,len parameters as we 
> >> do in most functions(truncate, bdevdiscard, getdents).
> >> It allow userspace caller to implement a fancy looking progress bars.
> >
> > Hi,
> >
> > do you think it is really needed when even with todays SSD's it takes
> > just a couple of seconds ? And I suppose it will improve in future. But
> > generally I think we can do that..I would like to hear some more
> > opinions before I start looking at this.
> Hi, Lukas
> we may face a really long delays due to bad layouts and slow devices
> Please read my response to Ted
> I'm agree with you what this interface is important, BTW i already
> enabled FITRIM support on my notebook, my speed difference is about 2-3%.
> But let's provide right user interface from very beginning.

Hi, Dimitry

I read the thread and really it makes sense to me. Sometimes it can be useful
to have more fine-grained control beside just specifying minlen argument,
which works quite well, however it is a little bit fuzzy because when you do
not know how much space was actually trimmed.

I think that there is no need to have two separate ioctls, even though
it would be more effective to specify block group instead of block range.
I am thinking about something like int optimize which will tell us to round
the range to block group boundaries. But I can not tell if it would
really help someone (probably not).

So I will try to do something to be able to break the FITRIM to smaller
pieces, uint64_t start, uint64_t len, uint64_t minlen seems good to me.

Thanks

-Lukas
--
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