All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Czerner <lczerner@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Lukas Czerner <lczerner@redhat.com>,
	linux-ext4@vger.kernel.org, jmoyer@redhat.com,
	rwheeler@redhat.com, eshishki@redhat.com, sandeen@redhat.com
Subject: Re: [PATCH 1/2] Add discard/nodiscard mount option for ext3
Date: Mon, 12 Jul 2010 18:01:39 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1007121753440.13784@localhost> (raw)
In-Reply-To: <20100712155007.GF3356@quack.suse.cz>

On Mon, 12 Jul 2010, Jan Kara wrote:

> On Mon 12-07-10 17:26:49, Lukas Czerner wrote:
> > On Mon, 12 Jul 2010, Jan Kara wrote:
> > 
> > > > Those mount option has the same meaning as in ext4 file system. It
> > > > provide a way to enable/disable file system's trim support. The trim
> > > > support is off by default, thus nodiscard option is not actually
> > > > necessary.
> > >   I kind of miss why ext3 should have a 'discard' mount option. When
> > > user calls DISCARD ioctl on the filesystem, then he probably wants
> > > discard to be performed.
> > > 
> > > 								Honza
> > 
> > You're right that it is not necessarily needed, but it is the same as in
> > ext4.
>   For ext4 it's a bit different matter as it automatically sends discard
> requests from mballoc when a block is freed. It makes a good sense to have
> an option to enable / disable this. But even for ext4 it would make sense
> to me to be able to allow this ioctl but still disable the logic for
> automatic trimming... Thus my suggestion would be to make 'discard' mount
> option only influence automatic trimming in ext4 and consequently it does
> not make sense to have such an option for ext3...
> 
> > If you want to be really sure that no unwanted trim will be send to the
> > device, 'nodiscard' mount option becomes handy. But I do not insist on it
> > and I can easily get rid of it.
>   Yeah, but the ioctl can be unsafe only if there are HW bugs or the trim
> support is buggy. Of course, both can happen but I don't think it's serious
> enough to warrant a new mount option (as that costs us something as well -
> too much options => user confusion ;).
> 
> 								Honza

You're probably right, it is not needed for ext3. And since my patch for
ext4 removes the old 'send trim when block is freed' implementation, I guess
it is not needed there either.

-Lukas

  reply	other threads:[~2010-07-12 16:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 13:18 Ext3: batched discard support Lukas Czerner
2010-07-07 13:18 ` [PATCH 1/2] Add discard/nodiscard mount option for ext3 Lukas Czerner
2010-07-12 15:19   ` Jan Kara
2010-07-12 15:26     ` Lukas Czerner
2010-07-12 15:50       ` Jan Kara
2010-07-12 16:01         ` Lukas Czerner [this message]
2010-07-12 15:27     ` Ric Wheeler
2010-07-12 16:03     ` Ric Wheeler
2010-07-12 16:05       ` Lukas Czerner
2010-07-12 16:15         ` Lukas Czerner
2010-07-12 18:07           ` Eric Sandeen
2010-07-07 13:18 ` [PATCH 2/2] Add batched discard support " Lukas Czerner
2010-07-12 15:28   ` Jan Kara
2010-07-12 15:58     ` Lukas Czerner
2010-07-12 19:57       ` Jan Kara
2010-07-13 15:55         ` Lukas Czerner
2010-07-07 19:14 ` Ext3: batched discard support Greg Freemyer
2010-07-09  8:53   ` Lukas Czerner
2010-07-09 10:18     ` Ric Wheeler
2010-07-12 15:09       ` Jan Kara

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.1007121753440.13784@localhost \
    --to=lczerner@redhat.com \
    --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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.