[jira] [Comment Edited] (TS-745) Support ssd

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631084#comment-13631084 ] 

Leif Hedstrom edited comment on TS-745 at 4/13/13 4:34 PM:
-----------------------------------------------------------

We had a long, heated discussion about this, so capturing some of this in this email.

First, we all agree that this should be a "Tiered Cache", and not specific to SSD. So code and configs etc. should properly reflect that.

Secondly, I obviously dislike the idea of storing some disk configs in storage.config, and some in records.config. I understand making this change is a big deal for Taobao, so I'm offering a compromise:

1) We add support for storage.config, with a new tag similar to the tag TS-1728 adds for volume identification. Maybe something like
{code}
/dev/sda tier=1
/dev/sdb tier=1
/dev/sdc tier=2
/dev/sdd tier=2
{code}

Where tier=1 is "SSD" (or whatever fast storage device you have, what currently gets configured in records.config) and tier=2 is all other disks (what's currently in storage.config).

2) In addition, we keep the records.config setting in mgmt/RecordsConfig.cc, and make it "populate" the tier=1 disks. This option will not be documented, or added to records.config.default.in. It's purely there to allow Taobao to merge with upstream and not having to maintain a fork. Long term, I'd imagine this config goes away, as we refactor all the configuraitons into a unified "VirtualHost" conceptual config.

James and I (and hopefully John too) will continue reviewing this complicated piece of code in the next week or two. The goal is to land this for v3.3.3, which is Mid-May. We do need to make sure this also doesn't conflict with TS-1728, which also should be landed for v3.3.3.


Feedback please.
                
      was (Author: zwoop):
    We had a long, heated discussion about this, so capturing some of this in this email.

First, we all agree that this should be a "Tiered Cache", and not specific to SSD. So code and configs etc. should properly reflect that.

Secondly, I obviously dislike the idea of storing some disk configs in storage.config, and some in records.config. I understand making this change is a big deal for Taobao, so I'm offering a compromise:

1) We add support for storage.config, with a new tag similar to the tag TS-1728. Maybe something like
{code}
/dev/sda tier=1
/dev/sdb tier=1
/dev/sdc tier=2
/dev/sdd tier=2
{code}

Where tier=1 is "SSD" (or whatever fast storage device you have, what currently gets configured in records.config) and tier=2 is all other disks (what's currently in storage.config).

2) In addition, we keep the records.config setting in mgmt/RecordsConfig.cc, and make it "populate" the tier=1 disks. This option will not be documented, or added to records.config.default.in. It's purely there to allow Taobao to merge with upstream and not having to maintain a fork. Long term, I'd imagine this config goes away, as we refactor all the configuraitons into a unified "VirtualHost" conceptual config.

James and I (and hopefully John too) will continue reviewing this complicated piece of code in the next week or two. The goal is to land this for v3.3.3, which is Mid-May. We do need to make sure this also doesn't conflict with TS-1728, which also should be landed for v3.3.3.


Feedback please.
                  
> Support ssd
> -----------
>
>                 Key: TS-745
>                 URL: https://issues.apache.org/jira/browse/TS-745
>             Project: Traffic Server
>          Issue Type: New Feature
>          Components: Cache
>            Reporter: mohan_zl
>            Assignee: weijin
>             Fix For: 3.3.4
>
>         Attachments: ts-745.diff, TS-ssd-2.patch, TS-ssd.patch
>
>
> A patch for supporting, not work well for a long time with --enable-debug

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira