Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Prof. Dr. Klaus Kusche]

I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.

 From the reviews I've read so far, two things became obvious:
* The SSD's I'm looking at really want a working SATA TRIM command.
* All the onboard Marvell 88SE9128 (or ASmedia) solutions
seriuosly lack performance, as do PCIe cards based on those chips.

So basically, there seem to be two choices:
1.) LSI 2008
2.) Marvell 9485

1.) seems to be fast, reliable and well-supported,
but as far as I can tell, it doesn't support TRIM at all:
It neither maps SCSI unmap to SATA TRIM,
nor accepts TRIM as a SATA passthrough command.

Is that true?

I didn't find much about 2.)
* The only cards based on this chip are the HighPoint 27xx,
or did I miss something?
* Running a 27xx with the mvsas driver was reported to have stability
problems or random errors. Are these problems solved?
* Is the 27xx fast (with SATA SSD's & mvsas driver),
i.e. significantly faster than onboard SATA 3 Gb/s ports?
* Does the 27xx+mvsas support TRIM when connected to SATA drives?

Are there any other solutions?

-- 
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche@computerix.info http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche@nta-isny.de http://www.nta-isny.de

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Douglas Gilbert]

On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>
>  From the reviews I've read so far, two things became obvious:
> * The SSD's I'm looking at really want a working SATA TRIM command.
> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
> seriuosly lack performance, as do PCIe cards based on those chips.
>
> So basically, there seem to be two choices:
> 1.) LSI 2008
> 2.) Marvell 9485
>
> 1.) seems to be fast, reliable and well-supported,
> but as far as I can tell, it doesn't support TRIM at all:
> It neither maps SCSI unmap to SATA TRIM,
> nor accepts TRIM as a SATA passthrough command.
>
> Is that true?

What counts in Linux for "trim" support on a SSD (SATA,
SAS or FC) is correctly processing the SCSI WRITE SAME (16)
with the UNMAP bit set. In the case of a SATA SSD, a SCSI
to ATA Translation Layer (SATL) should map that SCSI WRITE
SAME (16) with the UNMAP bit set to the ATA DATA SET
MANAGEMENT command with the TRIM attribute set.

Many Linux SATA low level drivers use libata which
implements the above mapping. However some SAS HBAs
(e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
in their own HBA firmware.

I tested a LSI SAS 9212-4i4e HBA running its most recent
firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
which does support trim. I used my ddpt utility and the
SCSI WRITE SAME (16) with the UNMAP bit set was rejected
as an "illegal request". With the UNMAP bit clear it
accepted the command. I also checked the SCSI UNMAP
command and it was also rejected.

LSI have some more work to do on their firmware.

Doug Gilbert


> I didn't find much about 2.)
> * The only cards based on this chip are the HighPoint 27xx,
> or did I miss something?
> * Running a 27xx with the mvsas driver was reported to have stability
> problems or random errors. Are these problems solved?
> * Is the 27xx fast (with SATA SSD's & mvsas driver),
> i.e. significantly faster than onboard SATA 3 Gb/s ports?
> * Does the 27xx+mvsas support TRIM when connected to SATA drives?
>
> Are there any other solutions?

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Douglas Gilbert]

On 11-08-11 03:59 PM, Douglas Gilbert wrote:
> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>
>> From the reviews I've read so far, two things became obvious:
>> * The SSD's I'm looking at really want a working SATA TRIM command.
>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>> seriuosly lack performance, as do PCIe cards based on those chips.
>>
>> So basically, there seem to be two choices:
>> 1.) LSI 2008
>> 2.) Marvell 9485
>>
>> 1.) seems to be fast, reliable and well-supported,
>> but as far as I can tell, it doesn't support TRIM at all:
>> It neither maps SCSI unmap to SATA TRIM,
>> nor accepts TRIM as a SATA passthrough command.
>>
>> Is that true?
>
> What counts in Linux for "trim" support on a SSD (SATA,
> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
> to ATA Translation Layer (SATL) should map that SCSI WRITE
> SAME (16) with the UNMAP bit set to the ATA DATA SET
> MANAGEMENT command with the TRIM attribute set.
>
> Many Linux SATA low level drivers use libata which
> implements the above mapping. However some SAS HBAs
> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
> in their own HBA firmware.
>
> I tested a LSI SAS 9212-4i4e HBA running its most recent
> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
> which does support trim. I used my ddpt utility and the
> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
> as an "illegal request". With the UNMAP bit clear it
> accepted the command. I also checked the SCSI UNMAP
> command and it was also rejected.
>
> LSI have some more work to do on their firmware.

I did check the LSI support page for my HBA just before sending
my original reply. And the version 9 firmware was showing at the
top of the list. Alas, that page had been alpha sorted on the
file names so that version 10 of the firmware (May 2011) was
hiding further down the page :-)

So I installed the newest firmware and redid the above tests.
Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
that SSD. The SCSI UNMAP command was rejected and I did not
test sending the ATA DATA SET MANAGEMENT command through
the pass-through (but I expect that would work).

So Linux file systems will be able "discard" (="unmap"(SCSI);
="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
which are running recent firmware.

Doug Gilbert

>> I didn't find much about 2.)
>> * The only cards based on this chip are the HighPoint 27xx,
>> or did I miss something?
>> * Running a 27xx with the mvsas driver was reported to have stability
>> problems or random errors. Are these problems solved?
>> * Is the 27xx fast (with SATA SSD's & mvsas driver),
>> i.e. significantly faster than onboard SATA 3 Gb/s ports?
>> * Does the 27xx+mvsas support TRIM when connected to SATA drives?
>>
>> Are there any other solutions?

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Stefan /*St0fF*/ Hübner]

Douglas,

have you double-checked to use the IT (Initiator Mode) Firmware from
LSI?  I mean we build up systems based on the X8SI6-F mainboard from
Supermicro which has a LSI SAS2008 with 8 Lanes on-board.  If using
HW-RAID (Modes 0, 1, 1E, ...) on those, we have to flash the "IR"
firmware.  If using the chip as HBA for Linux software RAID, we flash
the "IT" firmware, and if the customer needs HW-RAID5-Support, they get
an extra chip onto the board and we have to flash "iMR" firmware...

So you have 3 different firmware versions.  IT would be the way to go
here...

Greets,
Stefan

Am 12.08.2011 05:19, schrieb Douglas Gilbert:
> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>
>>> From the reviews I've read so far, two things became obvious:
>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>
>>> So basically, there seem to be two choices:
>>> 1.) LSI 2008
>>> 2.) Marvell 9485
>>>
>>> 1.) seems to be fast, reliable and well-supported,
>>> but as far as I can tell, it doesn't support TRIM at all:
>>> It neither maps SCSI unmap to SATA TRIM,
>>> nor accepts TRIM as a SATA passthrough command.
>>>
>>> Is that true?
>>
>> What counts in Linux for "trim" support on a SSD (SATA,
>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>> MANAGEMENT command with the TRIM attribute set.
>>
>> Many Linux SATA low level drivers use libata which
>> implements the above mapping. However some SAS HBAs
>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>> in their own HBA firmware.
>>
>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>> which does support trim. I used my ddpt utility and the
>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>> as an "illegal request". With the UNMAP bit clear it
>> accepted the command. I also checked the SCSI UNMAP
>> command and it was also rejected.
>>
>> LSI have some more work to do on their firmware.
> 
> I did check the LSI support page for my HBA just before sending
> my original reply. And the version 9 firmware was showing at the
> top of the list. Alas, that page had been alpha sorted on the
> file names so that version 10 of the firmware (May 2011) was
> hiding further down the page :-)
> 
> So I installed the newest firmware and redid the above tests.
> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
> that SSD. The SCSI UNMAP command was rejected and I did not
> test sending the ATA DATA SET MANAGEMENT command through
> the pass-through (but I expect that would work).
> 
> So Linux file systems will be able "discard" (="unmap"(SCSI);
> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
> which are running recent firmware.
> 
> Doug Gilbert
> 
>>> I didn't find much about 2.)
>>> * The only cards based on this chip are the HighPoint 27xx,
>>> or did I miss something?
>>> * Running a 27xx with the mvsas driver was reported to have stability
>>> problems or random errors. Are these problems solved?
>>> * Is the 27xx fast (with SATA SSD's & mvsas driver),
>>> i.e. significantly faster than onboard SATA 3 Gb/s ports?
>>> * Does the 27xx+mvsas support TRIM when connected to SATA drives?
>>>
>>> Are there any other solutions?
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Douglas Gilbert]

Stefan,
My test was done with IT firmware.

Actually I switched from IR (initiator raid?) to IT
(initiator target) firmware in the process of upgrading
from 9 to 10. [Wouldn't it be great if someone would
hookup these controllers in target mode to the Linux
kernel's new target infrastructure.]

As far as I have seen, most LSI SAS HBAs come with IR
firmware on them. Switching IR to IT firmware with
their sas2flash tool is a bit of a pain. First sas2flash
didn't work on a AMD 64 bit platform (DOS to the rescue),
then it refuses to load IT over IR firmware. The latter
problem is solved by clearing the flash ("-o -e 6" was
the magic for the clear (in the past when I did
"-o -e 7" I had to program the controller's SAS address
back in by hand)).

Doug Gilbert


On 11-08-12 03:16 AM, Stefan /*St0fF*/ Hübner wrote:
> Douglas,
>
> have you double-checked to use the IT (Initiator Mode) Firmware from
> LSI?  I mean we build up systems based on the X8SI6-F mainboard from
> Supermicro which has a LSI SAS2008 with 8 Lanes on-board.  If using
> HW-RAID (Modes 0, 1, 1E, ...) on those, we have to flash the "IR"
> firmware.  If using the chip as HBA for Linux software RAID, we flash
> the "IT" firmware, and if the customer needs HW-RAID5-Support, they get
> an extra chip onto the board and we have to flash "iMR" firmware...
>
> So you have 3 different firmware versions.  IT would be the way to go
> here...
>
> Greets,
> Stefan
>
> Am 12.08.2011 05:19, schrieb Douglas Gilbert:
>> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>>
>>>>  From the reviews I've read so far, two things became obvious:
>>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>>
>>>> So basically, there seem to be two choices:
>>>> 1.) LSI 2008
>>>> 2.) Marvell 9485
>>>>
>>>> 1.) seems to be fast, reliable and well-supported,
>>>> but as far as I can tell, it doesn't support TRIM at all:
>>>> It neither maps SCSI unmap to SATA TRIM,
>>>> nor accepts TRIM as a SATA passthrough command.
>>>>
>>>> Is that true?
>>>
>>> What counts in Linux for "trim" support on a SSD (SATA,
>>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>>> MANAGEMENT command with the TRIM attribute set.
>>>
>>> Many Linux SATA low level drivers use libata which
>>> implements the above mapping. However some SAS HBAs
>>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>>> in their own HBA firmware.
>>>
>>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>>> which does support trim. I used my ddpt utility and the
>>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>>> as an "illegal request". With the UNMAP bit clear it
>>> accepted the command. I also checked the SCSI UNMAP
>>> command and it was also rejected.
>>>
>>> LSI have some more work to do on their firmware.
>>
>> I did check the LSI support page for my HBA just before sending
>> my original reply. And the version 9 firmware was showing at the
>> top of the list. Alas, that page had been alpha sorted on the
>> file names so that version 10 of the firmware (May 2011) was
>> hiding further down the page :-)
>>
>> So I installed the newest firmware and redid the above tests.
>> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
>> that SSD. The SCSI UNMAP command was rejected and I did not
>> test sending the ATA DATA SET MANAGEMENT command through
>> the pass-through (but I expect that would work).
>>
>> So Linux file systems will be able "discard" (="unmap"(SCSI);
>> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
>> which are running recent firmware.
>>
>> Doug Gilbert
>>
>>>> I didn't find much about 2.)
>>>> * The only cards based on this chip are the HighPoint 27xx,
>>>> or did I miss something?
>>>> * Running a 27xx with the mvsas driver was reported to have stability
>>>> problems or random errors. Are these problems solved?
>>>> * Is the 27xx fast (with SATA SSD's&  mvsas driver),
>>>> i.e. significantly faster than onboard SATA 3 Gb/s ports?
>>>> * Does the 27xx+mvsas support TRIM when connected to SATA drives?
>>>>
>>>> Are there any other solutions?
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Stefan Hübner]

Hi Doug,

that indeed is right - it's kind of a pita and took me some time to make
a well-suited DOS-bootstick for basic hardware initialization...

But actually Supermicro.nl at least provides good support and how-to's
(via mail if you ask support@supermicro.nl).  And there should have bee
a correct script for flashing from IR to IT (including the erase-option,
if you took the Supermicro-package).

Cheers,
Stefan

Am 12.08.2011 15:42, schrieb Douglas Gilbert:
> Stefan,
> My test was done with IT firmware.
> 
> Actually I switched from IR (initiator raid?) to IT
> (initiator target) firmware in the process of upgrading
> from 9 to 10. [Wouldn't it be great if someone would
> hookup these controllers in target mode to the Linux
> kernel's new target infrastructure.]
> 
> As far as I have seen, most LSI SAS HBAs come with IR
> firmware on them. Switching IR to IT firmware with
> their sas2flash tool is a bit of a pain. First sas2flash
> didn't work on a AMD 64 bit platform (DOS to the rescue),
> then it refuses to load IT over IR firmware. The latter
> problem is solved by clearing the flash ("-o -e 6" was
> the magic for the clear (in the past when I did
> "-o -e 7" I had to program the controller's SAS address
> back in by hand)).
> 
> Doug Gilbert
> 
> 
> On 11-08-12 03:16 AM, Stefan /*St0fF*/ Hübner wrote:
>> Douglas,
>>
>> have you double-checked to use the IT (Initiator Mode) Firmware from
>> LSI?  I mean we build up systems based on the X8SI6-F mainboard from
>> Supermicro which has a LSI SAS2008 with 8 Lanes on-board.  If using
>> HW-RAID (Modes 0, 1, 1E, ...) on those, we have to flash the "IR"
>> firmware.  If using the chip as HBA for Linux software RAID, we flash
>> the "IT" firmware, and if the customer needs HW-RAID5-Support, they get
>> an extra chip onto the board and we have to flash "iMR" firmware...
>>
>> So you have 3 different firmware versions.  IT would be the way to go
>> here...
>>
>> Greets,
>> Stefan
>>
>> Am 12.08.2011 05:19, schrieb Douglas Gilbert:
>>> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>>>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>>>
>>>>>  From the reviews I've read so far, two things became obvious:
>>>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>>>
>>>>> So basically, there seem to be two choices:
>>>>> 1.) LSI 2008
>>>>> 2.) Marvell 9485
>>>>>
>>>>> 1.) seems to be fast, reliable and well-supported,
>>>>> but as far as I can tell, it doesn't support TRIM at all:
>>>>> It neither maps SCSI unmap to SATA TRIM,
>>>>> nor accepts TRIM as a SATA passthrough command.
>>>>>
>>>>> Is that true?
>>>>
>>>> What counts in Linux for "trim" support on a SSD (SATA,
>>>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>>>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>>>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>>>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>>>> MANAGEMENT command with the TRIM attribute set.
>>>>
>>>> Many Linux SATA low level drivers use libata which
>>>> implements the above mapping. However some SAS HBAs
>>>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>>>> in their own HBA firmware.
>>>>
>>>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>>>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>>>> which does support trim. I used my ddpt utility and the
>>>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>>>> as an "illegal request". With the UNMAP bit clear it
>>>> accepted the command. I also checked the SCSI UNMAP
>>>> command and it was also rejected.
>>>>
>>>> LSI have some more work to do on their firmware.
>>>
>>> I did check the LSI support page for my HBA just before sending
>>> my original reply. And the version 9 firmware was showing at the
>>> top of the list. Alas, that page had been alpha sorted on the
>>> file names so that version 10 of the firmware (May 2011) was
>>> hiding further down the page :-)
>>>
>>> So I installed the newest firmware and redid the above tests.
>>> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
>>> that SSD. The SCSI UNMAP command was rejected and I did not
>>> test sending the ATA DATA SET MANAGEMENT command through
>>> the pass-through (but I expect that would work).
>>>
>>> So Linux file systems will be able "discard" (="unmap"(SCSI);
>>> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
>>> which are running recent firmware.
>>>
>>> Doug Gilbert
>>>
>>>>> I didn't find much about 2.)
>>>>> * The only cards based on this chip are the HighPoint 27xx,
>>>>> or did I miss something?
>>>>> * Running a 27xx with the mvsas driver was reported to have stability
>>>>> problems or random errors. Are these problems solved?
>>>>> * Is the 27xx fast (with SATA SSD's&  mvsas driver),
>>>>> i.e. significantly faster than onboard SATA 3 Gb/s ports?
>>>>> * Does the 27xx+mvsas support TRIM when connected to SATA drives?
>>>>>
>>>>> Are there any other solutions?
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Prof. Dr. Klaus Kusche]

On 2011-08-12 05:19, Douglas Gilbert wrote:
> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>
>>> From the reviews I've read so far, two things became obvious:
>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>
>>> So basically, there seem to be two choices:
>>> 1.) LSI 2008
>>> 2.) Marvell 9485
>>>
>>> 1.) seems to be fast, reliable and well-supported,
>>> but as far as I can tell, it doesn't support TRIM at all:
>>> It neither maps SCSI unmap to SATA TRIM,
>>> nor accepts TRIM as a SATA passthrough command.
>>>
>>> Is that true?
>>
>> What counts in Linux for "trim" support on a SSD (SATA,
>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>> MANAGEMENT command with the TRIM attribute set.
>>
>> Many Linux SATA low level drivers use libata which
>> implements the above mapping. However some SAS HBAs
>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>> in their own HBA firmware.
>>
>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>> which does support trim. I used my ddpt utility and the
>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>> as an "illegal request". With the UNMAP bit clear it
>> accepted the command. I also checked the SCSI UNMAP
>> command and it was also rejected.
>>
>> LSI have some more work to do on their firmware.
>
> I did check the LSI support page for my HBA just before sending
> my original reply. And the version 9 firmware was showing at the
> top of the list. Alas, that page had been alpha sorted on the
> file names so that version 10 of the firmware (May 2011) was
> hiding further down the page :-)
>
> So I installed the newest firmware and redid the above tests.
> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
> that SSD. The SCSI UNMAP command was rejected and I did not
> test sending the ATA DATA SET MANAGEMENT command through
> the pass-through (but I expect that would work).
>
> So Linux file systems will be able "discard" (="unmap"(SCSI);
> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
> which are running recent firmware.

Was that with the RAID or the non-RAID firmware?

I've asked LSI sales/support about UNMAP/TRIM being supported.
They've opened a case, but I got zero response up to now.
So it doesn't seem to be on the official feature list,
and it seems to be unknown at least in the Munich LSI office.

Am I correct that this would support online trimming (mount discard),
but not batch trimming with wiper.sh or similar tools/scripts,
because they issue TRIM or UNMAP directly, not WRITE SAME UNMAP?
(what's the SCSI equivalent to the wiper.sh script?)

Nobody having any info's about Marvell / mvsas?

Klaus.

-- 
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche@computerix.info http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche@nta-isny.de http://www.nta-isny.de

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Ric Wheeler]

On 08/12/2011 09:04 AM, Prof. Dr. Klaus Kusche wrote:
> On 2011-08-12 05:19, Douglas Gilbert wrote:
>> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>>
>>>> From the reviews I've read so far, two things became obvious:
>>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>>
>>>> So basically, there seem to be two choices:
>>>> 1.) LSI 2008
>>>> 2.) Marvell 9485
>>>>
>>>> 1.) seems to be fast, reliable and well-supported,
>>>> but as far as I can tell, it doesn't support TRIM at all:
>>>> It neither maps SCSI unmap to SATA TRIM,
>>>> nor accepts TRIM as a SATA passthrough command.
>>>>
>>>> Is that true?
>>>
>>> What counts in Linux for "trim" support on a SSD (SATA,
>>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>>> MANAGEMENT command with the TRIM attribute set.
>>>
>>> Many Linux SATA low level drivers use libata which
>>> implements the above mapping. However some SAS HBAs
>>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>>> in their own HBA firmware.
>>>
>>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>>> which does support trim. I used my ddpt utility and the
>>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>>> as an "illegal request". With the UNMAP bit clear it
>>> accepted the command. I also checked the SCSI UNMAP
>>> command and it was also rejected.
>>>
>>> LSI have some more work to do on their firmware.
>>
>> I did check the LSI support page for my HBA just before sending
>> my original reply. And the version 9 firmware was showing at the
>> top of the list. Alas, that page had been alpha sorted on the
>> file names so that version 10 of the firmware (May 2011) was
>> hiding further down the page :-)
>>
>> So I installed the newest firmware and redid the above tests.
>> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
>> that SSD. The SCSI UNMAP command was rejected and I did not
>> test sending the ATA DATA SET MANAGEMENT command through
>> the pass-through (but I expect that would work).
>>
>> So Linux file systems will be able "discard" (="unmap"(SCSI);
>> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
>> which are running recent firmware.
>
> Was that with the RAID or the non-RAID firmware?
>
> I've asked LSI sales/support about UNMAP/TRIM being supported.
> They've opened a case, but I got zero response up to now.
> So it doesn't seem to be on the official feature list,
> and it seems to be unknown at least in the Munich LSI office.
>
> Am I correct that this would support online trimming (mount discard),
> but not batch trimming with wiper.sh or similar tools/scripts,
> because they issue TRIM or UNMAP directly, not WRITE SAME UNMAP?
> (what's the SCSI equivalent to the wiper.sh script?)
>
> Nobody having any info's about Marvell / mvsas?
>
> Klaus.
>

Discard issues the same SCSI command regardless of the online versus batch 
operation. If one works, the other should work as well.

Regards,

Ric

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Prof. Dr. Klaus Kusche]

On 2011-08-12 10:15, Ric Wheeler wrote:
> On 08/12/2011 09:04 AM, Prof. Dr. Klaus Kusche wrote:
>> On 2011-08-12 05:19, Douglas Gilbert wrote:
>>> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>>>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>>>
>>>>> From the reviews I've read so far, two things became obvious:
>>>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>>>
>>>>> So basically, there seem to be two choices:
>>>>> 1.) LSI 2008
>>>>> 2.) Marvell 9485
>>>>>
>>>>> 1.) seems to be fast, reliable and well-supported,
>>>>> but as far as I can tell, it doesn't support TRIM at all:
>>>>> It neither maps SCSI unmap to SATA TRIM,
>>>>> nor accepts TRIM as a SATA passthrough command.
>>>>>
>>>>> Is that true?
>>>>
>>>> What counts in Linux for "trim" support on a SSD (SATA,
>>>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>>>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>>>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>>>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>>>> MANAGEMENT command with the TRIM attribute set.
>>>>
>>>> Many Linux SATA low level drivers use libata which
>>>> implements the above mapping. However some SAS HBAs
>>>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>>>> in their own HBA firmware.
>>>>
>>>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>>>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>>>> which does support trim. I used my ddpt utility and the
>>>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>>>> as an "illegal request". With the UNMAP bit clear it
>>>> accepted the command. I also checked the SCSI UNMAP
>>>> command and it was also rejected.
>>>>
>>>> LSI have some more work to do on their firmware.
>>>
>>> I did check the LSI support page for my HBA just before sending
>>> my original reply. And the version 9 firmware was showing at the
>>> top of the list. Alas, that page had been alpha sorted on the
>>> file names so that version 10 of the firmware (May 2011) was
>>> hiding further down the page :-)
>>>
>>> So I installed the newest firmware and redid the above tests.
>>> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
>>> that SSD. The SCSI UNMAP command was rejected and I did not
>>> test sending the ATA DATA SET MANAGEMENT command through
>>> the pass-through (but I expect that would work).
>>>
>>> So Linux file systems will be able "discard" (="unmap"(SCSI);
>>> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
>>> which are running recent firmware.
>>
>> Was that with the RAID or the non-RAID firmware?
>>
>> I've asked LSI sales/support about UNMAP/TRIM being supported.
>> They've opened a case, but I got zero response up to now.
>> So it doesn't seem to be on the official feature list,
>> and it seems to be unknown at least in the Munich LSI office.
>>
>> Am I correct that this would support online trimming (mount discard),
>> but not batch trimming with wiper.sh or similar tools/scripts,
>> because they issue TRIM or UNMAP directly, not WRITE SAME UNMAP?
>> (what's the SCSI equivalent to the wiper.sh script?)
>>
>> Nobody having any info's about Marvell / mvsas?
>>
>> Klaus.
>>
>
> Discard issues the same SCSI command regardless of the online versus
> batch operation. If one works, the other should work as well.

I don't think so. wiper.sh/hdparm issue an ATA DSM TRIM as a
passthrough command in believe, not a WRITE SAME UNMAP.
And I've seen scripts doing the same as wiper.sh for SCSI
by calling the sg_unmap utility, which results in UNMAP,
not WRITE SAME UNMAP.

Klaus.

-- 
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche@computerix.info http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche@nta-isny.de http://www.nta-isny.de

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Ric Wheeler]

On 08/12/2011 09:48 AM, Prof. Dr. Klaus Kusche wrote:
> On 2011-08-12 10:15, Ric Wheeler wrote:
>> On 08/12/2011 09:04 AM, Prof. Dr. Klaus Kusche wrote:
>>> On 2011-08-12 05:19, Douglas Gilbert wrote:
>>>> On 11-08-11 03:59 PM, Douglas Gilbert wrote:
>>>>> On 11-08-11 11:18 AM, Prof. Dr. Klaus Kusche wrote:
>>>>>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>>>>>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>>>>>
>>>>>> From the reviews I've read so far, two things became obvious:
>>>>>> * The SSD's I'm looking at really want a working SATA TRIM command.
>>>>>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>>>>>> seriuosly lack performance, as do PCIe cards based on those chips.
>>>>>>
>>>>>> So basically, there seem to be two choices:
>>>>>> 1.) LSI 2008
>>>>>> 2.) Marvell 9485
>>>>>>
>>>>>> 1.) seems to be fast, reliable and well-supported,
>>>>>> but as far as I can tell, it doesn't support TRIM at all:
>>>>>> It neither maps SCSI unmap to SATA TRIM,
>>>>>> nor accepts TRIM as a SATA passthrough command.
>>>>>>
>>>>>> Is that true?
>>>>>
>>>>> What counts in Linux for "trim" support on a SSD (SATA,
>>>>> SAS or FC) is correctly processing the SCSI WRITE SAME (16)
>>>>> with the UNMAP bit set. In the case of a SATA SSD, a SCSI
>>>>> to ATA Translation Layer (SATL) should map that SCSI WRITE
>>>>> SAME (16) with the UNMAP bit set to the ATA DATA SET
>>>>> MANAGEMENT command with the TRIM attribute set.
>>>>>
>>>>> Many Linux SATA low level drivers use libata which
>>>>> implements the above mapping. However some SAS HBAs
>>>>> (e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
>>>>> in their own HBA firmware.
>>>>>
>>>>> I tested a LSI SAS 9212-4i4e HBA running its most recent
>>>>> firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
>>>>> which does support trim. I used my ddpt utility and the
>>>>> SCSI WRITE SAME (16) with the UNMAP bit set was rejected
>>>>> as an "illegal request". With the UNMAP bit clear it
>>>>> accepted the command. I also checked the SCSI UNMAP
>>>>> command and it was also rejected.
>>>>>
>>>>> LSI have some more work to do on their firmware.
>>>>
>>>> I did check the LSI support page for my HBA just before sending
>>>> my original reply. And the version 9 firmware was showing at the
>>>> top of the list. Alas, that page had been alpha sorted on the
>>>> file names so that version 10 of the firmware (May 2011) was
>>>> hiding further down the page :-)
>>>>
>>>> So I installed the newest firmware and redid the above tests.
>>>> Now the SCSI WRITE SAME (16) with the UNMAP bit set works on
>>>> that SSD. The SCSI UNMAP command was rejected and I did not
>>>> test sending the ATA DATA SET MANAGEMENT command through
>>>> the pass-through (but I expect that would work).
>>>>
>>>> So Linux file systems will be able "discard" (="unmap"(SCSI);
>>>> ="trim"(ATA)) data using LSI HBAs based the LSI 2008 chip
>>>> which are running recent firmware.
>>>
>>> Was that with the RAID or the non-RAID firmware?
>>>
>>> I've asked LSI sales/support about UNMAP/TRIM being supported.
>>> They've opened a case, but I got zero response up to now.
>>> So it doesn't seem to be on the official feature list,
>>> and it seems to be unknown at least in the Munich LSI office.
>>>
>>> Am I correct that this would support online trimming (mount discard),
>>> but not batch trimming with wiper.sh or similar tools/scripts,
>>> because they issue TRIM or UNMAP directly, not WRITE SAME UNMAP?
>>> (what's the SCSI equivalent to the wiper.sh script?)
>>>
>>> Nobody having any info's about Marvell / mvsas?
>>>
>>> Klaus.
>>>
>>
>> Discard issues the same SCSI command regardless of the online versus
>> batch operation. If one works, the other should work as well.
>
> I don't think so. wiper.sh/hdparm issue an ATA DSM TRIM as a
> passthrough command in believe, not a WRITE SAME UNMAP.
> And I've seen scripts doing the same as wiper.sh for SCSI
> by calling the sg_unmap utility, which results in UNMAP,
> not WRITE SAME UNMAP.
>
> Klaus.
>

wiper.sh is not the tool I was talking about, that came from Mark Lord and you 
are right, it is ATA specific.  Not sure if Mark can/wants to make it more 
generic, but that might be worth doing.

Lukas has a more generic bulk tool that should do the job and has the advantage 
that it does not have to fill the file system first (it can lock regions and do 
its work).

Note that discard is not just for physical devices like SCSI or ATA, it is also 
useful for "software" stacks like various device mapper targets, virtual block 
devices, etc so we should be keeping the abstraction at a high level for our 
tooling.

Ric

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Prof. Dr. Klaus Kusche]

On 2011-08-12 11:01, Ric Wheeler wrote:
> Lukas has a more generic bulk tool that should do the job and has the
> advantage that it does not have to fill the file system first (it can
> lock regions and do its work).

Any pointers to that?

Thanks!

> Note that discard is not just for physical devices like SCSI or ATA, it
> is also useful for "software" stacks like various device mapper targets,
> virtual block devices, etc so we should be keeping the abstraction at a
> high level for our tooling.

I agree, but wiper.sh has been the first such tool and is widespread
and well-known. I'm not aware of alternatives using the generic fstrim
command (which is still missing on some major distributions)
or FITRIM ioctl.

-- 
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche@computerix.info http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche@nta-isny.de http://www.nta-isny.de

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Ric Wheeler]

On 08/12/2011 10:24 AM, Prof. Dr. Klaus Kusche wrote:
> On 2011-08-12 11:01, Ric Wheeler wrote:
>> Lukas has a more generic bulk tool that should do the job and has the
>> advantage that it does not have to fill the file system first (it can
>> lock regions and do its work).
>
> Any pointers to that?

I think that the easiest (and most natural way) to do this is through the 
updated fsck (-K) tool which will discard the unused block ranges when you fsck 
a file system.

Lukas can add in details about versions, etc :)

>
> Thanks!
>
>> Note that discard is not just for physical devices like SCSI or ATA, it
>> is also useful for "software" stacks like various device mapper targets,
>> virtual block devices, etc so we should be keeping the abstraction at a
>> high level for our tooling.
>
> I agree, but wiper.sh has been the first such tool and is widespread
> and well-known. I'm not aware of alternatives using the generic fstrim
> command (which is still missing on some major distributions)
> or FITRIM ioctl.
>

FITRIM is somewhat misnamed. It will end up issuing a discard to the storage 
stack, not an ATA specific TRIM command (invoking sb_issue_discard()).

Anything that uses FITRIM should work if I followed the code correctly,

Ric

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Lukas Czerner]

On Fri, 12 Aug 2011, Ric Wheeler wrote:

> On 08/12/2011 10:24 AM, Prof. Dr. Klaus Kusche wrote:
> > On 2011-08-12 11:01, Ric Wheeler wrote:
> > > Lukas has a more generic bulk tool that should do the job and has the
> > > advantage that it does not have to fill the file system first (it can
> > > lock regions and do its work).
> > 
> > Any pointers to that?
> 
> I think that the easiest (and most natural way) to do this is through the
> updated fsck (-K) tool which will discard the unused block ranges when you
> fsck a file system.
> 
> Lukas can add in details about versions, etc :)

Yes, you can use e2fsck to discard unused parst of the file system,
hence reclaiming the space. This feature has been added with
v1.41.12-162-gefa1a35 into e2fsprogs. Note that even though this
operation should be safe, because we do discard at the end of the pass 5
and only if there was not any errors on the file system before, however
this is relatively new feature and has not been extensively tested with
corrupted images.

Hmm, I really should write up this stuff into the web article somewhere
:).

Thanks!
-Lukas


> 
> > 
> > Thanks!
> > 
> > > Note that discard is not just for physical devices like SCSI or ATA, it
> > > is also useful for "software" stacks like various device mapper targets,
> > > virtual block devices, etc so we should be keeping the abstraction at a
> > > high level for our tooling.
> > 
> > I agree, but wiper.sh has been the first such tool and is widespread
> > and well-known. I'm not aware of alternatives using the generic fstrim
> > command (which is still missing on some major distributions)
> > or FITRIM ioctl.
> > 
> 
> FITRIM is somewhat misnamed. It will end up issuing a discard to the storage
> stack, not an ATA specific TRIM command (invoking sb_issue_discard()).
> 
> Anything that uses FITRIM should work if I followed the code correctly,
> 
> Ric
> 
> 
> 
> 

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Lukas Czerner]

On Fri, 12 Aug 2011, Prof. Dr. Klaus Kusche wrote:

> On 2011-08-12 11:01, Ric Wheeler wrote:
> > Lukas has a more generic bulk tool that should do the job and has the
> > advantage that it does not have to fill the file system first (it can
> > lock regions and do its work).
> 
> Any pointers to that?
> 
> Thanks!
> 
> > Note that discard is not just for physical devices like SCSI or ATA, it
> > is also useful for "software" stacks like various device mapper targets,
> > virtual block devices, etc so we should be keeping the abstraction at a
> > high level for our tooling.
> 
> I agree, but wiper.sh has been the first such tool and is widespread
> and well-known. I'm not aware of alternatives using the generic fstrim
> command (which is still missing on some major distributions)
> or FITRIM ioctl.
> 

wiper.sh is just a hack to do rally nasty thing to the filesystam
(allocating all free space), so I have never tried that. But on newer
kernel with FITRIM ioctl and filesystem which implements it, you can
easily use fstrim tool. It is part of the util-linux-ng since
v2.18-165-gd9e2d0d.

Every discard implementation I know of in kernel uses the same
infrastructure so there should be no difference between online (-o
discard) or batched discard (FITRIM) or even between specific file
system implementations. There was some efforts in introducing vectored
discard command support which can batch more extents into the single
command, but IMO it is not anywhere near ready.

Other than that I do no know of any other alternatives.

Thanks!
-Lukas

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Mark Lord]

On 11-08-12 05:52 AM, Lukas Czerner wrote:
..
> wiper.sh is just a hack to do rally nasty thing to the filesystam
> (allocating all free space)

It actually does NOT allocate all of the free space,
but yes it does reserve *most* of it, leaving a few percent
or a few hundred MB free while it issues the DSM/TRIM commands.

And it uses the fallocate system call, so the reserved space
is not actually written to when reserved, nor when later freed.

I expect the next version of it to include support for FSTRIM,
but that is a much slower method, especially for offline TRIM.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Artem Bokhan]

On 11.08.2011 22:18, Prof. Dr. Klaus Kusche wrote:
> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>
> From the reviews I've read so far, two things became obvious:
> * The SSD's I'm looking at really want a working SATA TRIM command.
> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
> seriuosly lack performance, as do PCIe cards based on those chips.
>
> So basically, there seem to be two choices:
> 1.) LSI 2008

IT firmware supports TRIM. You may use 
ftp://ftp.supermicro.com/driver/SAS/LSI/2008/ tools to flash IR firmware instead 
of iMR (megaraid), then flash to IT firmware. Then you may flash latest IT 
firmware to ensure that TRIM is supported.

Re: Good SAS adapters for 6 Gb/s SATA SSD's (with TRIM)?

[Artem Bokhan]

http://www.google.ru/url?sa=t&source=web&cd=3&ved=0CC0QFjAC&url=http%3A%2F%2Fkb.lsi.com%2FExportPDF16515.aspx&rct=j&q=lsi%20trim&ei=PPNETuzgLIfMtAaoyKy4Bw&usg=AFQjCNFo139XTAeHefm4nnvHbrW52OZ7ug&cad=rja 
<http://www.google.ru/url?sa=t&source=web&cd=3&ved=0CC0QFjAC&url=http%3A%2F%2Fkb.lsi.com%2FExportPDF16515.aspx&rct=j&q=lsi%20trim&ei=PPNETuzgLIfMtAaoyKy4Bw&usg=AFQjCNFo139XTAeHefm4nnvHbrW52OZ7ug&cad=rja>

On 12.08.2011 16:17, Artem Bokhan wrote:
> On 11.08.2011 22:18, Prof. Dr. Klaus Kusche wrote:
>> I'm looking for ways to hook up fast 6 Gb/s SATA SSD's (non-RAID!)
>> to (server or i-X58) mainboards which do not have native 6 Gb/s SATA.
>>
>> From the reviews I've read so far, two things became obvious:
>> * The SSD's I'm looking at really want a working SATA TRIM command.
>> * All the onboard Marvell 88SE9128 (or ASmedia) solutions
>> seriuosly lack performance, as do PCIe cards based on those chips.
>>
>> So basically, there seem to be two choices:
>> 1.) LSI 2008
>
> IT firmware supports TRIM. You may use 
> ftp://ftp.supermicro.com/driver/SAS/LSI/2008/ tools to flash IR firmware 
> instead of iMR (megaraid), then flash to IT firmware. Then you may flash 
> latest IT firmware to ensure that TRIM is supported.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html