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:	Wed, 4 Aug 2010 11:26:56 -0400
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Lukas Czerner <lczerner@...hat.com>
Cc:	Dmitry Monakhov <dmonakhov@...nvz.org>, linux-ext4@...r.kernel.org,
	jmoyer@...hat.com, rwheeler@...hat.com, eshishki@...hat.com,
	sandeen@...hat.com, jack@...e.cz, tytso@....edu,
	Mark Lord <kernel@...savvy.com>
Subject: Re: [PATCH 1/3] Add ioctl FITRIM.

On Wed, Aug 4, 2010 at 11:13 AM, Lukas Czerner <lczerner@...hat.com> wrote:
> 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.
>
> Thanks.
>
> -Lukas.

Since the proposed patch is not aggregating discards into multiple
ranges per ATA command, I thought some of the non-optimized devices
would take minutes / hours?

If true, a way to control the progress from userspace is important.

If in general it is only going to take a few seconds for a full FITRIM
to run, it is much less important, but I suppose the the RT project
might find even that problematic.

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