Andreas Sundstrom wrote:
> Hi..
>
> I have an OCZ agility SSD drive with FW 1.5 that supports the TRIM command.
>
> I can see that it works on a plain partition.
> But it does not seem to work together with LVM.
>
> So I'm wondering if this is expected and whether it is something that
> will be worked on to get fixed?
It is expected, as lvm is not yet passing discard requests.
I'd ask next on the LVM lists ;)
-Eric
> Otherwise I guess that I will consider reverting back to plain
> partitions on my SSD drive.
>
> Thanks for any help
>
> /Andreas Sundstrom
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> "Eric" == Eric Sandeen <[email protected]> writes:
Eric> Andreas Sundstrom wrote:
>> Hi..
>>
>> I have an OCZ agility SSD drive with FW 1.5 that supports the TRIM
>> command.
>>
>> I can see that it works on a plain partition. But it does not seem
>> to work together with LVM.
>>
>> So I'm wondering if this is expected and whether it is something that
>> will be worked on to get fixed?
Eric> It is expected, as lvm is not yet passing discard requests.
I'm working on this. Missed the 2.6.34 merge window so I'm aiming at
2.6.35.
--
Martin K. Petersen Oracle Linux Engineering
Martin K. Petersen wrote:
>>>>>> "Eric" == Eric Sandeen <[email protected]> writes:
>
> Eric> Andreas Sundstrom wrote:
>>> Hi..
>>>
>>> I have an OCZ agility SSD drive with FW 1.5 that supports the
>>> TRIM command.
>>>
>>> I can see that it works on a plain partition. But it does not
>>> seem to work together with LVM.
>>>
>>> So I'm wondering if this is expected and whether it is something
>>> that will be worked on to get fixed?
>
> Eric> It is expected, as lvm is not yet passing discard requests.
>
> I'm working on this. Missed the 2.6.34 merge window so I'm aiming at
> 2.6.35.
Ah, that sounds good. I tried mailing the dm-devel list but my mail
didn't seem to make it. Let me know if you need testing done for this,
I should be able to test it if you want.
/Andreas
On Sun, Mar 7, 2010 at 12:38 PM, Martin K. Petersen
<[email protected]> wrote:
>>>>>> "Eric" == Eric Sandeen <[email protected]> writes:
>
> Eric> Andreas Sundstrom wrote:
>>> Hi..
>>>
>>> I have an OCZ agility SSD drive with FW 1.5 that supports the TRIM
>>> command.
>>>
>>> I can see that it works on a plain partition. ?But it does not seem
>>> to work together with LVM.
>>>
>>> So I'm wondering if this is expected and whether it is something that
>>> will be worked on to get fixed?
>
> Eric> It is expected, as lvm is not yet passing discard requests.
>
> I'm working on this. ?Missed the 2.6.34 merge window so I'm aiming at
> 2.6.35.
Hey Martin,
We've been scoping the work associated with adding discard support to
DM (afaik MD would need comparable infrastructure, e.g.: spliting
discard requests).
There is a fair amount of complexity associated with this work.
Especially when you look to support discards for some of the more
advanced DM targets. Discard support for the 'linear' target is the
relatively low hanging fruit. The 'striped' target gets more
interesting (having to split the discard into multiple discards to
submit to the appropriate underlying devices in the striped volume).
One thought was we might have a block layer hook along the lines of
the q->merge_bvec_fn (similar but hopefully less
problematic/controversial). Christoph removed a hook that was vaguely
like this, but posed allocation problems, with linux-2.6 commit:
c15227de132f
Please feel free to share your patches/design with dm-devel. (I'll
also check with Alasdair to see about making the dm-devel filtering
less prone to eat mail)
Thanks!
Mike
>>>>> "Mike" == Mike Snitzer <[email protected]> writes:
Mike> We've been scoping the work associated with adding discard support
Mike> to DM (afaik MD would need comparable infrastructure, e.g.:
Mike> spliting discard requests).
Mike> There is a fair amount of complexity associated with this work.
Mike> Especially when you look to support discards for some of the more
Mike> advanced DM targets. Discard support for the 'linear' target is
Mike> the relatively low hanging fruit. The 'striped' target gets more
Mike> interesting (having to split the discard into multiple discards to
Mike> submit to the appropriate underlying devices in the striped
Mike> volume).
Mike> One thought was we might have a block layer hook along the lines
Mike> of the q->merge_bvec_fn (similar but hopefully less
Mike> problematic/controversial). Christoph removed a hook that was
Mike> vaguely like this, but posed allocation problems, with linux-2.6
Mike> commit: c15227de132f
This is a work in progress and something that turned out to be much
harder than I anticipated. Discard is not the only problem child here.
The other one is write same. In both cases we'll have to split things
that cover an area bigger than the corresponding bio_vec payload.
At first I took the blk_pc splitting approach but it got really hairy
and had lots of special casing. So what I'm working on right now is to
make write same and discard requests first class citizens so they can be
split and merged like regular write requests. There are lots of
assumptions in our stack about things being either read or write so it's
a pretty invasive change. But at this point it looks like it'll be
nicer than my first attempt. Still plugging away at it though...
--
Martin K. Petersen Oracle Linux Engineering