On Wed, Aug 4, 2010 at 11:13 AM, Lukas Czerner <lczerner@xxxxxxxxxx> wrote: > On Wed, 4 Aug 2010, Dmitry Monakhov wrote: > >> Lukas Czerner <lczerner@xxxxxxxxxx> writes: >> >> > Adds an filesystem independent ioctl to allow implementation of file >> > system batched discard support. >> > >> > Signed-off-by: Lukas Czerner <lczerner@xxxxxxxxxx> >> > --- >> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
