From: Eric Sandeen <sandeen@redhat.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: Ric Wheeler <rwheeler@redhat.com>, Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org, jmoyer@redhat.com,
eshishki@redhat.com
Subject: Re: [PATCH 1/2] Add discard/nodiscard mount option for ext3
Date: Mon, 12 Jul 2010 13:07:59 -0500 [thread overview]
Message-ID: <4C3B59FF.3040200@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1007121813100.2733@localhost>
On 07/12/2010 11:15 AM, Lukas Czerner wrote:
> On Mon, 12 Jul 2010, Lukas Czerner wrote:
>
>> On Mon, 12 Jul 2010, Ric Wheeler wrote:
>>
>>> On 07/12/2010 11:19 AM, 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
>>>>
>>>
>>> Sorry I misunderstood your original question.
>>>
>>> One reason that you might want to have a "discard" option is to allow a system
>>> admin to mount without barriers to protect flaky hardware (we have had some
>>> mixed results for example). As you say, the user probably wants to have the
>>> ioctl do the discard and should be reasonable for doing it only on solid
>>> devices,
>>
>> The question is what in does on device other than SSD. I know it does
>> not harm the deivce, but is there some kernel logic preventing the trim
>> command to be send to device that does not support it ? I hope so.
>>
>
> Yes, there is a check whether device support trim in blkdev_issue_discard
> code.
I also sent an ext4 patch so that a failed discard clears the flag so we
don't keep attempting more.
However, the LVM guys aren't too happy with that because they point to
cases like:
a) pvmove off of, and back onto, a trim-capable device
b) composite devices of trim-capable and -incapable devices
I don't care much either way, I don't think we do much harm in
continuing to send discards after a failure; the original motivation for
the patch was so that if a user asked for discard and the (simple)
device didn't support it, they'd get a message, and we'd stop trying.
-Eric
> -Lukas
next prev parent reply other threads:[~2010-07-12 18:08 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
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 [this message]
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=4C3B59FF.3040200@redhat.com \
--to=sandeen@redhat.com \
--cc=eshishki@redhat.com \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@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.