|
Replies:
34
-
Last Post:
Dec 30, 2007 8:21 PM
by: gwr
|
|
|
Posts:
466
From:
US
Registered:
12/21/05
|
|
|
|
OpenSolaris Storage Wishlist
Posted:
May 9, 2007 10:12 PM
To: Communities » storage » discuss
|
|
Obviously Storage is a big area, just look at the technologies represented on http://www.opensolaris.org/os/community/storage/.
And just as obviously we probably have a lot on our plates for new development. But we want to gather project ideas into a wishlist for OpenSolaris Storage. I.e., we know what is already on our plates, but we want to find out what we need to start planning for the next course.
A common exercise in developmental departments is the 18 month roadmap planning. Each subgoup gets together (say NFS) and considers all of the projects that they would like to work on in the next year and a half. They try to get rough time estimates and priorities in place.
They also try to get individual engineers to buy into working on certain projects. A reality is that we want engineers to be working on projects that they are excited about.
And those subgroups take those ideas to a meeting of the departmental management and senior engineers. (Sometimes it is the other way around, the management and senior engineers come to subgroup meetings with lists of approved projects.) And then they hash out where the department is going to allocate resources for the next 18 months.
I just realized I'm kinda doing product marketing. ;>
Anyway, it is time we as a OpenSolaris Community put together a wish list of projects that we want to start putting on the Storage roadmap.
Please feel free to propose project ideas to the storage-discuss forum.
|
|
|
Posts:
764
From:
US
Registered:
9/21/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 10, 2007 6:10 AM
in response to: tdh
|
|
> Please feel free to propose project ideas to the storage-discuss forum.
Well for me:
1) I'd like to see more filesystem support: XFS, Raiser, ext3, JFS,
NTFS (full ACL/NTpersimissions support)
2) lash friendly filesystems: squahfs and jffs2 (+ future jffs3)
3) Better support of US/Firewire drives. (I still have to try this
out, so don't flame me if I am out of date)
4) A standard OpenSolaris/open source SRM suite. (provisioning+)
5) Support for holographic storage. (Just checking to see if you are
still reading)
6) Scalable OpenSource backup software. (Not sure is StorageTech had
something they could opensource)
7) Rewrite/refactor SAM/QFS to simplify ease of use/installation and management.
8) Support more cluster file systems.
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,361
From:
US
Registered:
8/5/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 10, 2007 6:59 AM
in response to: tdh
|
|
On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
> Anyway, it is time we as a OpenSolaris Community put
> together a wish list of projects that we want to start
> putting on the Storage roadmap.
- The ability to have ZFS support prioritized writes such that they
hit the fastest disks first, then are later re-written to slower
disks. The intent is that then a device like Thumper could use a
couple solid state disks as a write cache to speed up small file or
attribute intensive NFS I/O. Is it sufficient to just put the ZIL on
the SSDs?
- pNFS along with integration with with ZFS or availability suite to
dynamically migrate data between NFS servers (for load balancing or
NFS server retirement) with no client outage. I haven't read the pNFS
drafts yet, so perhaps my expectations are a bit high.
- ZFS quotas that don't charge for snapshots. If the admin of a
storage server keeps snapshots for backup, compliance, or some other
reason, in most cases I don't want this to impact the end user of the
storage.
- NDMP enabled "zfs send". This seems like the most promising way to
do block-level backups of ZFS in a way that cleanly integrates with
enterprise backup products. Every serious backup vendor around
supports NDMP for file server appliance backups.
- Block level de-duplication. Maintain a database of checksum to
block mappings. If checksums match, do full contents comparison. If
the blocks are the same store multiple references to the same block.
This should work across all file systems in a pool. If a large number
of home directories (each on their on FS) each have their own copy of
the same data ("copy ~cs500/dataset.tar.gz ~, then untar it") one copy
should be stored. Dedup could happen on the fly or as a background
re-write that uses available CPU and spindle time.
- Bug the people that are working on hardware-accelerated crypto in
Sun's chips to do the same for compression. Use these offload engines
for file system compression so that the rest of the CPU is available
for other workloads. Maybe this isn't really needed: perhaps just
have the ability to prioritize compression by file system and use of
processor sets for compression would be sufficient. (Today it looks
like shared serves with zfs compression can have one workload dominate
CPU usage in a way that ignores existing CPU resource controls.)
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
22
From:
Colorado
Registered:
8/25/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 4, 2007 4:31 AM
in response to: mgerdts
|
|
On May 10, 2007, at 7:59 AM, Mike Gerdts wrote:
> On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
>> Anyway, it is time we as a OpenSolaris Community put
>> together a wish list of projects that we want to start
>> putting on the Storage roadmap.
>
> - The ability to have ZFS support prioritized writes such that they
> hit the fastest disks first, then are later re-written to slower
> disks. The intent is that then a device like Thumper could use a
> couple solid state disks as a write cache to speed up small file or
> attribute intensive NFS I/O. Is it sufficient to just put the ZIL on
> the SSDs?
Mike -
Just to clarify here, are you goals simply to speed up overall reads/
writes? I'd like to understand what you really want to achieve and
capture this in the wish-list.
/Scott
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,361
From:
US
Registered:
8/5/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 4, 2007 10:18 AM
in response to: rt86616
|
|
On 6/4/07, Scott Tracy <Scott dot Tracy at sun dot com> wrote:
> On May 10, 2007, at 7:59 AM, Mike Gerdts wrote:
> > On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
> >> Anyway, it is time we as a OpenSolaris Community put
> >> together a wish list of projects that we want to start
> >> putting on the Storage roadmap.
> >
> > - The ability to have ZFS support prioritized writes such that they
> > hit the fastest disks first, then are later re-written to slower
> > disks. The intent is that then a device like Thumper could use a
> > couple solid state disks as a write cache to speed up small file or
> > attribute intensive NFS I/O. Is it sufficient to just put the ZIL on
> > the SSDs?
>
> Just to clarify here, are you goals simply to speed up overall reads/
> writes? I'd like to understand what you really want to achieve and
> capture this in the wish-list.
The goal here is to minimize the time required for bits (avoiding the
term data to not confuse data vs. metadata) to be committed to stable
storage, thereby speeding up operations that are particularly picky
about being sure that writes are committed before moving on. Small
file and attribute intensive workloads, particularly over NFS, are key
examples of workloads that this targets.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
198
From:
USA
Registered:
1/10/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 10, 2007 7:35 AM
in response to: tdh
|
|
On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
> Please feel free to propose project ideas to the storage-discuss forum.
I would like to see the following items added to opensolaris:
1. FMA hardened SAN and Ethernet drivers (since Ethernet is the most
common interface type used with iSCSI, I thought I would add it).
2. FMA support for SMART, and a tool to view SMART data (it sounds
like the FMA sensor project is going to add basic SMART support, but
no generic tool to view SMART data).
3. Integrate the disk failure heuristics from the CMU and google
papers into a disk / IO diagnosis engine.
4. HBA virtualization (i.e., crossbow for HBAs).
5. It would be nice to be able to defragment ZFS file systems to
relayout blocks in an optimal fashion.
6. Ability to prioritize the system resources devoted to background
scrubbing and defragment operations (assuming defragmentation support
is added).
7. Better out of the box performance for the iSCSI stack (there are a
couple bugs that deal with this, and it would be nice to get the
workarounds incorporated into opensolaris).
8. Better error messages in the iscsiadm and iscsitadm utilities.
Thanks,
- Ryan
--
UNIX Administrator
http://prefetch.net
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
64
From:
US
Registered:
3/9/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 10, 2007 5:27 PM
in response to: matty
|
|
Matty wrote:
> On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
>
>> Please feel free to propose project ideas to the storage-discuss forum.
>
> I would like to see the following items added to opensolaris:
>
>
> 4. HBA virtualization (i.e., crossbow for HBAs).
Have you looked at NPIV? We are looking at this for Solaris
FibreChannel stack
See:
http://blogs.sun.com/AaronDailey/entry/npiv_and_solaris_fibrechannel
Or do you envision something else?
Aaron
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
22
From:
Colorado
Registered:
8/25/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 4, 2007 4:22 AM
in response to: matty
|
|
Ryan -
These are great items. I'd like to get some clarification on some of
them just to make sure we're thinking along the same lines. Comments
in-line:
On May 10, 2007, at 8:35 AM, Matty wrote:
> On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
>
>> Please feel free to propose project ideas to the storage-discuss
>> forum.
>
> I would like to see the following items added to opensolaris:
>
> 1. FMA hardened SAN and Ethernet drivers (since Ethernet is the most
> common interface type used with iSCSI, I thought I would add it).
>
> 2. FMA support for SMART, and a tool to view SMART data (it sounds
> like the FMA sensor project is going to add basic SMART support, but
> no generic tool to view SMART data).
The questions I have here revolve around the tool to view the SMART
data.
How do you envision this looking and working? Would you prefer a CLI-
based tool or more GUI-based?
>
> 3. Integrate the disk failure heuristics from the CMU and google
> papers into a disk / IO diagnosis engine.
Can you reference the papers here and talk a little bit about your
ideal expectations?
>
> 4. HBA virtualization (i.e., crossbow for HBAs).
Different than say NPIV, you would also like to see data
classification and prioritization here like cross-bow? In other
words QOS and virtualization?
>
> 5. It would be nice to be able to defragment ZFS file systems to
> relayout blocks in an optimal fashion.
>
> 6. Ability to prioritize the system resources devoted to background
> scrubbing and defragment operations (assuming defragmentation support
> is added).
>
> 7. Better out of the box performance for the iSCSI stack (there are a
> couple bugs that deal with this, and it would be nice to get the
> workarounds incorporated into opensolaris).
>
> 8. Better error messages in the iscsiadm and iscsitadm utilities.
Sure. Can you elaborate on what you are not seeing that you expect
to see?
Thanks!!
/Scott
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
42
From:
US
Registered:
5/3/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 4, 2007 5:10 PM
in response to: rt86616
|
|
Scott Tracy wrote:
> Ryan -
>
> These are great items. I'd like to get some clarification on some of
> them just to make sure we're thinking along the same lines. Comments
> in-line:
> On May 10, 2007, at 8:35 AM, Matty wrote:
>
>> On 5/10/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
>>
>>> Please feel free to propose project ideas to the storage-discuss forum.
>>
>>
>> I would like to see the following items added to opensolaris:
>>
>> 1. FMA hardened SAN and Ethernet drivers (since Ethernet is the most
>> common interface type used with iSCSI, I thought I would add it).
>>
>> 2. FMA support for SMART, and a tool to view SMART data (it sounds
>> like the FMA sensor project is going to add basic SMART support, but
>> no generic tool to view SMART data).
>
>
> The questions I have here revolve around the tool to view the SMART data.
> How do you envision this looking and working? Would you prefer a CLI-
> based tool or more GUI-based?
BTW, the following SMART data is available for SATA disk attached to
drivers that use the SATA framework.
1) SCSI mode sense page 0x1c (informational exception control page)
2) SCSI log sense page 0x10 (self test results)
3) SCSI log sense page 0x2f (informational exceptions)
4) SCSI log sense page 0x30 (Sun Solaris vendor specified SMART data page)
(the format of the returned data is defined in:
/usr/include/sys/sata/sata_defs.h)
I think that the smartmontools (from Linux) can be built for and run
on Solaris (remember, the disks appear to be SCSI disks, not ATA disks).
Regards,
Lida
>>
>> 3. Integrate the disk failure heuristics from the CMU and google
>> papers into a disk / IO diagnosis engine.
>
>
> Can you reference the papers here and talk a little bit about your
> ideal expectations?
>
>>
>> 4. HBA virtualization (i.e., crossbow for HBAs).
>
>
> Different than say NPIV, you would also like to see data classification
> and prioritization here like cross-bow? In other words QOS and
> virtualization?
>
>>
>> 5. It would be nice to be able to defragment ZFS file systems to
>> relayout blocks in an optimal fashion.
>>
>> 6. Ability to prioritize the system resources devoted to background
>> scrubbing and defragment operations (assuming defragmentation support
>> is added).
>>
>> 7. Better out of the box performance for the iSCSI stack (there are a
>> couple bugs that deal with this, and it would be nice to get the
>> workarounds incorporated into opensolaris).
>>
>> 8. Better error messages in the iscsiadm and iscsitadm utilities.
>
>
> Sure. Can you elaborate on what you are not seeing that you expect to
> see?
>
> Thanks!!
>
> /Scott
>
>
>
>
>
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Grant Zhang
Grant.Zhang@Sun.COM
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 4, 2007 6:33 PM
in response to: rt86616
|
|
Scott Tracy 写道:
>> 3. Integrate the disk failure heuristics from the CMU and google
>> papers into a disk / IO diagnosis engine.
>
>
> Can you reference the papers here and talk a little bit about your
> ideal expectations?
Scott,
The google paper on disk I/O would likely be this one:
http://labs.google.com/papers/disk_failures.pdf
Grant
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
198
From:
USA
Registered:
1/10/06
|
|
|
|
|
|
Posts:
381
From:
US
Registered:
1/24/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 6, 2007 3:15 PM
in response to: rt86616
|
|
Scott Tracy wrote:
> Ryan -
>>
>> 3. Integrate the disk failure heuristics from the CMU and google
>> papers into a disk / IO diagnosis engine.
>
> Can you reference the papers here and talk a little bit about your
> ideal expectations?
The infamous CMU, google, and MSFT papers. The generic takeaway from
those papers were that SATA drives were as likely to fail as their
"enterprise class" brethren. We talked about these a bit inside Sun and
basically came away with, "This data isn't very good without a
discussion around duty cycles".
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
5
From:
Colorado
Registered:
5/3/07
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 6, 2007 3:24 PM
in response to: tmcmahon
|
|
IMHO, "Duty Cycles" is a red herring. There's a lot of FUD around
interface positioning that's not grounded in Physics of Failure (or
field data) ... Bob
On Jun 6, 2007, at 4:15 PM, Torrey McMahon wrote:
> Scott Tracy wrote:
>> Ryan -
>>>
>>> 3. Integrate the disk failure heuristics from the CMU and google
>>> papers into a disk / IO diagnosis engine.
>>
>> Can you reference the papers here and talk a little bit about your
>> ideal expectations?
>
> The infamous CMU, google, and MSFT papers. The generic takeaway
> from those papers were that SATA drives were as likely to fail as
> their "enterprise class" brethren. We talked about these a bit
> inside Sun and basically came away with, "This data isn't very good
> without a discussion around duty cycles".
>
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
381
From:
US
Registered:
1/24/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 6, 2007 10:06 PM
in response to: bobwood
|
|
Most systems vendors have been telling customers to use SATA for smaller
workloads, tier 3, or data that isn't important. (Whatever that means
...) If the customer base has been following those recommendations then
the SATA drives haven't been utilized as much as the FC variety. To use
an obvious example: Saying that over a one year timeframe a SATA drive
that gets 100 iops a minute is as reliable as a FC drive that gets 100
iops per second puts the data into an other light. Not at the interface
level but where the majority of failures occur inside the drive housing
itself.
Robert B. Wood wrote:
> IMHO, "Duty Cycles" is a red herring. There's a lot of FUD around
> interface positioning that's not grounded in Physics of Failure (or
> field data) ... Bob
>
> On Jun 6, 2007, at 4:15 PM, Torrey McMahon wrote:
>
>> Scott Tracy wrote:
>>> Ryan -
>>>>
>>>> 3. Integrate the disk failure heuristics from the CMU and google
>>>> papers into a disk / IO diagnosis engine.
>>>
>>> Can you reference the papers here and talk a little bit about your
>>> ideal expectations?
>>
>> The infamous CMU, google, and MSFT papers. The generic takeaway from
>> those papers were that SATA drives were as likely to fail as their
>> "enterprise class" brethren. We talked about these a bit inside Sun
>> and basically came away with, "This data isn't very good without a
>> discussion around duty cycles".
>>
>> _______________________________________________
>> storage-discuss mailing list
>> storage-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
5
From:
Colorado
Registered:
5/3/07
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 7, 2007 6:30 AM
in response to: tmcmahon
|
|
It's pretty easy to understand vendor motivations behind recommending higher-end systems whenever possible. The conventional wisdom is that higher priced components should be more reliable than lower priced components, but as oft the case, this wisdom is flawed. To use a metaphor, it's like saying that a Ferrari is more reliable than a Hyundai. It certainly has higher performance (that's what it's designed for), but it's not more reliable (by far).
It helps to look under the covers of a disc drive, and a little deeper than the light pass given by "definitive papers" written by vendors in this space. What exactly do you expect to fail in a disc drive that is more utilized? Smoking head actuators, overheating write pre-amps? The fact is that the technologies are fundamentally the same in different classes of disc drives frm a given vendor. This applies to heads, media, bearing systems, ASIC vendors, FR4, manufacturing facilities, ..., etc. These vendors have "common platform" initiatives and seek leverage across their engineering and delivery processes just like everybody else does.
Actuators have a lighter second moment and other differences to halve the seek latency, and there are extra servo requirements associated with spinning a platter at twice the velocity, but the differences in design are related to performance objectives, not reliability.
It really is time to clip the reliability portion from this particular technology selection discussion. It's simply a matter of price-performance. You want random seek perfromance, pay more for the HDD.
... Bob On Jun 6, 2007, at 11:06 PM, Torrey McMahon wrote: Most systems vendors have been telling customers to use SATA for smaller workloads, tier 3, or data that isn't important. (Whatever that means ...) If the customer base has been following those recommendations then the SATA drives haven't been utilized as much as the FC variety. To use an obvious example: Saying that over a one year timeframe a SATA drive that gets 100 iops a minute is as reliable as a FC drive that gets 100 iops per second puts the data into an other light. Not at the interface level but where the majority of failures occur inside the drive housing itself.
Robert B. Wood wrote: IMHO, "Duty Cycles" is a red herring. There's a lot of FUD around interface positioning that's not grounded in Physics of Failure (or field data) ... Bob
On Jun 6, 2007, at 4:15 PM, Torrey McMahon wrote:
Scott Tracy wrote: Ryan -
3. Integrate the disk failure heuristics from the CMU and google papers into a disk / IO diagnosis engine.
Can you reference the papers here and talk a little bit about your ideal expectations?
The infamous CMU, google, and MSFT papers. The generic takeaway from those papers were that SATA drives were as likely to fail as their "enterprise class" brethren. We talked about these a bit inside Sun and basically came away with, "This data isn't very good without a discussion around duty cycles".
_______________________________________________ storage-discuss mailing list
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Emily Pollock
Emily.Pollock@Sun.COM
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 7, 2007 10:00 AM
in response to: bobwood
|
|
<pre style="margin-bottom: 0.2in;"> I would be careful about using the google (or even the CMU) paper to develop disk failure
heuristics. While the google paper does a good job of introducing potential variables to significantly
predict disk drive failure it ultimately fails to demonstrate that any of these factors actually do
accurately predict disk drive failure. As the last post pointed out, “It helps to look under the covers
of a disc drive, and a little deeper than the light pass given by "definitive papers" written by vendors
in this space. What exactly do you expect to fail in a disc drive that is more utilized?” Unfortunately,
the google paper does not answer this question and ultimately fails to aid in developing any disk drive
failure heuristics.</pre>
Robert B. Wood wrote:
It's pretty easy to understand vendor motivations behind
recommending higher-end systems whenever possible. The conventional
wisdom is that higher priced components should be more reliable
than lower priced components, but as oft the case, this wisdom is
flawed. To use a metaphor, it's like saying that a Ferrari is more
reliable than a Hyundai. It certainly has higher performance (that's
what it's designed for), but it's not more reliable (by far).
It helps to look under the covers of a disc drive, and a little
deeper than the light pass given by "definitive papers" written by
vendors in this space. What exactly do you expect to fail in a disc
drive that is more utilized? Smoking head actuators, overheating write
pre-amps? The fact is that the technologies are fundamentally the same
in different classes of disc drives frm a given vendor. This applies
to heads, media, bearing systems, ASIC vendors, FR4, manufacturing
facilities, ..., etc. These vendors have "common platform" initiatives
and seek leverage across their engineering and delivery processes just
like everybody else does.
Actuators have a lighter second moment and other differences to
halve the seek latency, and there are extra servo requirements
associated with spinning a platter at twice the velocity, but the
differences in design are related to performance objectives, not
reliability.
It really is time to clip the reliability portion from this
particular technology selection discussion. It's simply a matter of
price-performance. You want random seek perfromance, pay more for the
HDD.
... Bob
On Jun 6, 2007, at 11:06 PM, Torrey McMahon wrote:
Most systems vendors have been telling
customers to use SATA for smaller workloads, tier 3, or data that isn't
important. (Whatever that means ...) If the customer base has been
following those recommendations then the SATA drives haven't been
utilized as much as the FC variety. To use an obvious example: Saying
that over a one year timeframe a SATA drive that gets 100 iops a minute
is as reliable as a FC drive that gets 100 iops per second puts the
data into an other light. Not at the interface level but where the
majority of failures occur inside the drive housing itself.
Robert B. Wood wrote:
IMHO, "Duty Cycles" is a red herring. There's a lot of FUD around
interface positioning that's not grounded in Physics of Failure (or
field data) ... Bob
On Jun 6, 2007, at 4:15 PM, Torrey
McMahon wrote:
Scott Tracy wrote:
Ryan -
3. Integrate the disk failure
heuristics from the CMU and google
papers into a disk / IO diagnosis
engine.
Can you reference the papers here
and talk a little bit about your ideal expectations?
The infamous CMU, google, and MSFT
papers. The generic takeaway from those papers were that SATA drives
were as likely to fail as their "enterprise class" brethren. We talked
about these a bit inside Sun and basically came away with, "This data
isn't very good without a discussion around duty cycles".
_______________________________________________
storage-discuss mailing list
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
</pre>
|
|
|
|
|
Posts:
191
From:
US
Registered:
6/25/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 8, 2007 1:57 PM
in response to: bobwood
|
|
On Jun 7, 2007, at 09:31, Robert B. Wood wrote: It helps to look under the covers of a disc drive, and a little deeper than the light pass given by "definitive papers" written by vendors in this space. What exactly do you expect to fail in a disc drive that is more utilized? Smoking head actuators, overheating write pre-amps? The fact is that the technologies are fundamentally the same in different classes of disc drives from a given vendor. This applies to heads, media, bearing systems, ASIC vendors, FR4, manufacturing facilities, ..., etc. These vendors have "common platform" initiatives and seek leverage across their engineering and delivery processes just like everybody else does.
Okay - I'll bite - the effect of use and heat on bearing wear and platter re-readability over time .. if the bearing tolerance is lower, there's more of a tendency to write eliptical tracks which combined with heat defects on cheaper platter substrate can result in a higher BER (particular if the platters are more densely packed.) Actuators have a lighter second moment and other differences to halve the seek latency, and there are extra servo requirements associated with spinning a platter at twice the velocity, but the differences in design are related to performance objectives, not reliability.
I'm not so sure you can easily separate performance objectives from reliability objectives if you consider that a component may underperform over time than fail. It really is time to clip the reliability portion from this particular technology selection discussion. It's simply a matter of price-performance. You want random seek performance, pay more for the HDD.
Data access latency and data layout is often the key differentiator here .. let's not fill our heads with the notion that a "random seek" performance drive carries a higher cost since this can be more of an effect of the overall architecture, block layout, data retrieval and caching strategies. Actuator latency can be a key differentiator, but the bigger one (IMO) is typically the software that's on the drive (fcode, OS, application)
--- .je
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
198
From:
USA
Registered:
1/10/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 9, 2007 8:59 AM
in response to: rt86616
|
|
On 6/4/07, Scott Tracy <Scott dot Tracy at sun dot com> wrote:
> > 2. FMA support for SMART, and a tool to view SMART data (it sounds
> > like the FMA sensor project is going to add basic SMART support, but
> > no generic tool to view SMART data).
>
> The questions I have here revolve around the tool to view the SMART
> data.
> How do you envision this looking and working? Would you prefer a CLI-
> based tool or more GUI-based?
I like the default smartctl display, so maybe you could use that as a
reference? If you haven't used this nifty utility before, you might be
interested in the following article:
http://prefetch.net/articles/diskdrives.smart.html
> > 4. HBA virtualization (i.e., crossbow for HBAs).
>
> Different than say NPIV, you would also like to see data
> classification and prioritization here like cross-bow? In other
> words QOS and virtualization?
QOS and virtualized HBAs would be super useful, since you could tie
them to Solaris zones and eventually Xen DomUs.
> > 8. Better error messages in the iscsiadm and iscsitadm utilities.
>
> Sure. Can you elaborate on what you are not seeing that you expect
> to see?
There are a number of bugs files to make the errors a bit more
readable. If you need the specific bug numbers, I will try to dig them
up (I filed two of them).
Thanks,
- Ryan
--
UNIX Administrator
http://prefetch.net
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
22
From:
Colorado
Registered:
8/25/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 10, 2007 10:34 AM
in response to: matty
|
|
Thanks Ryan.
I'm in the process of taking a look at the tools associated with
SMART data.
I believe our future NPIV project intends to address the FC HBA's in
terms of QOS and virtualized HBA's, but don't see any other HBA's on
the immediate horizon. I'll capture this one and press onward to see
what is available in the industry.
Please do send me the bug numbers just to make sure we get them fixed
and also if you have other ideas.
Thanks for your help,
/Scott
On Jun 9, 2007, at 9:59 AM, Matty wrote:
> On 6/4/07, Scott Tracy <Scott dot Tracy at sun dot com> wrote:
>
>> > 2. FMA support for SMART, and a tool to view SMART data (it sounds
>> > like the FMA sensor project is going to add basic SMART support,
>> but
>> > no generic tool to view SMART data).
>>
>> The questions I have here revolve around the tool to view the SMART
>> data.
>> How do you envision this looking and working? Would you prefer a
>> CLI-
>> based tool or more GUI-based?
>
> I like the default smartctl display, so maybe you could use that as a
> reference? If you haven't used this nifty utility before, you might be
> interested in the following article:
>
> http://prefetch.net/articles/diskdrives.smart.html
>
>> > 4. HBA virtualization (i.e., crossbow for HBAs).
>>
>> Different than say NPIV, you would also like to see data
>> classification and prioritization here like cross-bow? In other
>> words QOS and virtualization?
>
> QOS and virtualized HBAs would be super useful, since you could tie
> them to Solaris zones and eventually Xen DomUs.
>
>> > 8. Better error messages in the iscsiadm and iscsitadm utilities.
>>
>> Sure. Can you elaborate on what you are not seeing that you expect
>> to see?
>
> There are a number of bugs files to make the errors a bit more
> readable. If you need the specific bug numbers, I will try to dig them
> up (I filed two of them).
>
>
> Thanks,
> - Ryan
> --
> UNIX Administrator
> http://prefetch.net
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Scott Tracy
Director
Sun Microsystems
SAN Software
303-225-7551
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
64
From:
US
Registered:
3/9/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 10, 2007 8:21 PM
in response to: matty
|
|
Matty wrote:
> On 6/4/07, Scott Tracy <Scott dot Tracy at sun dot com> wrote:
>
>> > 4. HBA virtualization (i.e., crossbow for HBAs).
>>
>> Different than say NPIV, you would also like to see data
>> classification and prioritization here like cross-bow? In other
>> words QOS and virtualization?
>
> QOS and virtualized HBAs would be super useful, since you could tie
> them to Solaris zones and eventually Xen DomUs.
Matty,
Can you clarify how you would use QOS? I think it's a good idea in
general, but use cases would be useful for design. For example, QOS
could guarantee HBA bandwidth to DOMUs in a Xen environment, or
dedicating IOPs to a specific application in a non hypervisor environment.
Also, how would you use virtual HBAs in a zone/DOMU? In the Xen
community there's been talk of a SCSI split device driver, that would
allow SCSI target devices to be assigned to a DOMU, and accessed using
SCSI instead of the current limitation of block access. Would this
address what you want to do?
Aaron
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Wilkinson, Alex
alex.wilkinson@dsto....
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 10, 2007 9:03 PM
in response to: matty
|
|
0n Sat, Jun 09, 2007 at 11:59:44AM -0400, Matty wrote:
> QOS and virtualized HBAs would be super useful, since you could tie
> them to Solaris zones and eventually Xen DomUs.
What is meant by "virtualized HBAs" ?
-aW
IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,640
From:
US
Registered:
6/14/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 8, 2007 1:59 AM
in response to: matty
To: Communities » storage » discuss
|
|
> 2. FMA support for SMART, and a tool to view SMART
> data (it sounds
> like the FMA sensor project is going to add basic
> SMART support, but
> no generic tool to view SMART data).
Have you looked at http://www.blastwave.org/packages.php/smartmontools ?
Not sure if that's anything like what you want to view the data, but it
might be a start, at least to see if there's anything there worth seeing.
|
|
|
|
|
Posts:
198
From:
USA
Registered:
1/10/06
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
Jun 8, 2007 1:12 PM
in response to: rlhamil
|
|
On 6/8/07, Richard L. Hamilton <rlhamil at smart dot net> wrote:
> > 2. FMA support for SMART, and a tool to view SMART
> > data (it sounds
> > like the FMA sensor project is going to add basic
> > SMART support, but
> > no generic tool to view SMART data).
>
> Have you looked at http://www.blastwave.org/packages.php/smartmontools ?
> Not sure if that's anything like what you want to view the data, but it
> might be a start, at least to see if there's anything there worth seeing.
I sure have, and think smartmontools is a great piece of software. It
would be nice though if Solaris came with a tool to view SMART
attributes, since it would reduce the number of third party
applications sites have to install and maintain.
Thanks,
- Ryan
--
UNIX Administrator
http://prefetch.net
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
4
From:
Registered:
3/20/07
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 11, 2007 11:30 AM
in response to: tdh
To: Communities » storage » discuss
|
|
Cluster filesystem support, either with zfs or qfs.
SR
|
|
|
|
|
Posts:
764
From:
US
Registered:
9/21/05
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
May 11, 2007 11:35 AM
in response to: sr2007
|
|
Tom,
Could you please post this list on genunix?
Thanks,
Brian
On 5/11/07, SR <sraja97 at gmail dot com> wrote:
> Cluster filesystem support, either with zfs or qfs.
>
> SR
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
198
From:
USA
Registered:
1/10/06
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
May 11, 2007 11:46 AM
in response to: sr2007
|
|
On 5/11/07, SR <sraja97 at gmail dot com> wrote:
> Cluster filesystem support, either with zfs or qfs.
ZFS cluster file system support would definitely be neat.
- Ryan
--
UNIX Administrator
http://prefetch.net
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
466
From:
US
Registered:
12/21/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 11, 2007 1:01 PM
in response to: tdh
To: Communities » storage » discuss
|
|
Wow, I've been holding back to see what trickled in and this is some really nice responses.
|
|
|
|
|
Posts:
100
From:
ZA
Registered:
6/15/05
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
May 14, 2007 1:44 AM
in response to: tdh
|
|
One of the most FAQ's regarding storage at customers is performance,
saturation, potential speedup etc. of different configs (current and
new).
Yes, I know this is a subject all on its own, but it would be very
helpfull to have a A-to-Z view of the I/O inrastructure ... be that
text of graphical.
#java io-a-to-z.jre ;)
A prog like this could give one a clear graphical (or text) view of a
system and the complete I/O insfrastrucure and performance throughout
the system.
HBA's, LUN's, Multiple paths, WWP names and phys paths ...
I/O's per second generated, response times in ms from application to
wait queue, onto service queue, throughput (MB/s), rise and fall of
various buffers, etc.. Together with processes generating those I/O's
and their impact on CPU...
Yes, I know using iostat, vmstat, mpstat and dtrace scripts can drill
down and give one a clear indication of what is going on, and yes,
writing ones own perl (kstat) application (which I did) can also help
to give a "top-like" overview of I/O.
However, surely the time has come to use a higher level prog to get
that initial overview and have support (like me) pointing in the right
direction?
PS: Or just hand over vdbench and swat :)
On 5/11/07, Tom Haynes <thomas dot haynes at sun dot com> wrote:
> Wow, I've been holding back to see what trickled in and this is some really nice responses.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
124
From:
Lodz, Poland
Registered:
3/3/07
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
May 14, 2007 2:05 AM
in response to: burgerw
|
|
On Mon, May 14, 2007 at 10:44:57AM +0200, Louwtjie Burger wrote:
> One of the most FAQ's regarding storage at customers is performance,
> saturation, potential speedup etc. of different configs (current and
> new).
>
> Yes, I know this is a subject all on its own, but it would be very
> helpfull to have a A-to-Z view of the I/O inrastructure ... be that
> text of graphical.
>
> #java io-a-to-z.jre ;)
>
> A prog like this could give one a clear graphical (or text) view of a
> system and the complete I/O insfrastrucure and performance throughout
> the system.
>
> HBA's, LUN's, Multiple paths, WWP names and phys paths ...
>
> I/O's per second generated, response times in ms from application to
> wait queue, onto service queue, throughput (MB/s), rise and fall of
> various buffers, etc.. Together with processes generating those I/O's
> and their impact on CPU...
>
> Yes, I know using iostat, vmstat, mpstat and dtrace scripts can drill
> down and give one a clear indication of what is going on, and yes,
> writing ones own perl (kstat) application (which I did) can also help
> to give a "top-like" overview of I/O.
>
> However, surely the time has come to use a higher level prog to get
> that initial overview and have support (like me) pointing in the right
> direction?
>
> PS: Or just hand over vdbench and swat :)
Perhaps Ortera http://www.ortera.com/ might be close to your needs.
Though I haven't used it yet ...
przemol
----------------------------------------------------------------------
Wygraj aparat cyfrowy lub komorke! Glosuj na Superjedynki!
>>> http://link.interia.pl/f1a82
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
764
From:
US
Registered:
9/21/05
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
May 14, 2007 2:55 AM
in response to: przemolb
|
|
I don't know if anyone has mentioned this, but it would be cool if the
LVM/FS layers supported de-duplication.
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
22
From:
Colorado
Registered:
8/25/06
|
|
|
|
Re: Re: OpenSolaris Storage Wishlist
Posted:
Jun 4, 2007 4:37 AM
in response to: burgerw
|
|
On May 14, 2007, at 2:44 AM, Louwtjie Burger wrote:
> One of the most FAQ's regarding storage at customers is performance,
> saturation, potential speedup etc. of different configs (current and
> new).
>
> Yes, I know this is a subject all on its own, but it would be very
> helpfull to have a A-to-Z view of the I/O inrastructure ... be that
> text of graphical.
>
> #java io-a-to-z.jre ;)
>
> A prog like this could give one a clear graphical (or text) view of a
> system and the complete I/O insfrastrucure and performance throughout
> the system.
>
> HBA's, LUN's, Multiple paths, WWP names and phys paths ...
>
> I/O's per second generated, response times in ms from application to
> wait queue, onto service queue, throughput (MB/s), rise and fall of
> various buffers, etc.. Together with processes generating those I/O's
> and their impact on CPU...
>
> Yes, I know using iostat, vmstat, mpstat and dtrace scripts can drill
> down and give one a clear indication of what is going on, and yes,
> writing ones own perl (kstat) application (which I did) can also help
> to give a "top-like" overview of I/O.
>
> However, surely the time has come to use a higher level prog to get
> that initial overview and have support (like me) pointing in the right
> direction?
>
> PS: Or just hand over vdbench and swat :)
>
Louwtjie -
I think I follow you here on what you want. What would you do with
this data that would help you in your daily activities?
/Scott
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
39
From:
Cambridge, UK
Registered:
7/27/06
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 16, 2007 2:30 PM
in response to: tdh
|
|
How about some improvements to udfs? Perhaps enhancing it to support
more recent versions of the UDF Specification?
I found a bug in mkfs_udfs where it gives the wrong sector size for some
SCSI optical drives (Bug ID 6453801) in July last year and suggested a
possible three line fix. The problem is still in OpenSolaris ...
Anybody else interested in a udfs project?
--
John Connett
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
764
From:
US
Registered:
9/21/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
May 17, 2007 2:30 PM
in response to: jconnett
|
|
Is someone putting this up on GENUNIX WIKI?
On 5/16/07, John Connett <jrc at skylon dot demon dot co dot uk> wrote:
> How about some improvements to udfs? Perhaps enhancing it to support
> more recent versions of the UDF Specification?
>
> I found a bug in mkfs_udfs where it gives the wrong sector size for some
> SCSI optical drives (Bug ID 6453801) in July last year and suggested a
> possible three line fix. The problem is still in OpenSolaris ...
>
> Anybody else interested in a udfs project?
> --
> John Connett
>
>
>
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
377
From:
US
Registered:
12/9/05
|
|
|
|
Re: OpenSolaris Storage Wishlist
Posted:
Jun 5, 2007 8:59 AM
in response to: tdh
|
|
On May 10, 2007, at 1:12 AM, Tom Haynes wrote:
> Please feel free to propose project ideas to the storage-discuss
> forum.
Here's my big wishlist item:
Standards-based storage management, preferably in the form of a SMI-S
based provider running on top of Solaris.
There's a problem with this though, in that pretty much all of the
mature storage management apps out there which speak SMI-S are quite
expensive and ornery. In this field, Sun offers ESM-AA which isn't
cheap. Sun has a rising star in the form of Common Array Manager
(CAM) which is currently geared towards managing their Engenio-based
StorageTek product line... but *could* be extended to support generic
SMI-S providers I gather.
IBM has their Tivoli suite, and there are one-off products from EMC
and the like which really only talk to their own storage products. In
the Open Source world, there is the Aperi which is maintained under
the Eclipse Project banner, and is being worked on by IBM wonks...
and has a heavy tilt towards running on Linux and AIX with a DB2
backend (yaaar!)
If would be SO nice if the Sun, stars, and planets could align to do
the following:
* Jump start a SMI-S provider and basic framework for it for Solaris
which has hooks down into ZFS, NFS, SMB for configuration management
and the I/O related kstats for performance monitoring.
* Perhaps look at opening up CAM and generic-izing it to deal with
the above, and make it it possible to write product-specific modules
for hardware that provides SMI-S (or not... eg; Apple Xserve RAID and
other arrays like that. The Apple product is seeing a huge adoption
in Solaris shops)
* ESM-AA.... ?? It's a big software suite... not sure how much money
it makes Sun or really how well it works since there's no demo
version available, but it has the SMI-S/CIMOM smarts to tie storage
devices and SAN switches together for that end-to-end storage
management.
Another wishlist thing... making real use of the ses driver in
Solaris. Perhaps a simple utility a la fcinfo (and NOT luxadm) to get
stats and monitoring from generic enclosures.
/dale
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
192
From:
US
Registered:
7/7/06
|
|
|
|
Re: OpenSolaris Storage Wishlist - Single instance storage, de-duplication
Posted:
Dec 30, 2007 8:21 PM
in response to: tdh
To: Communities » storage » discuss
Cc: Communities » zfs » discuss
|
|
I noticed two questions about Single instance storage (SIS) or de-duplication.
I'm curious too. Is there any activity that can be divulged here?
|
|
|
|
|
