Re: [zfs-discuss] alternative hardware configurations for zfs

[Damjan Perenic]

On Sat, Sep 12, 2009 at 7:25 AM, Tim Cook  wrote:
>
>
> On Fri, Sep 11, 2009 at 4:46 PM, Chris Du  wrote:
>>
>> You can optimize for better IOPS or for transfer speed. NS2 SATA and SAS
>> share most of the design, but they are still different, cache, interface,
>> firmware are all different.
>
> And I'm asking you to provide a factual basis for the interface playing any
> role in IOPS.  I know for a fact it has nothing to do with error recovery or
> command queue.
>
> Regardless, I've never seen either one provide any significant change in
> IOPS.  I feel fairly confident stating that within the storage industry
> there's a pretty well known range of IOPS provided for 7200, 10K, and 15K
> drives respectively, regardless of interface.  You appear to be saying this
> isn't the case, so I'd like to know what data you're using as a reference
> point.

I shopped for 1TB 7200rpm drives recently and I noticed Seagate
Barracude ES.2 has 1TB version with SATA and SAS interface.

In their datasheet at
http://www.seagate.com/www/en-us/products/servers/barracuda_es/ and
product overview they claim following:

---
Choose SAS for the seamless Tier 2 enterprise experience, with
improved data integrity and a 135 percent average performance
boost over SATA. SAS also reduces integration complexity and
optimizes system performance for rich media, reference data
storage and enterprise backup applications.
---
With a choice of either SATA or SAS
interfaces, the Barracuda ES.2 drive
utilizes perpendicular recording technology
to deliver the industry’s highest-capacity
4-platter drive. SAS delivers up to a 38
percent IOPS/watt improvement over
SATA.
---

And in Product overview:
---
• Full internal IOEDC/IOECC* data integrity protection on SAS models
• Dual-ported, multi-initiator SAS provides full-duplex compatibility
and a 135 percent average** performance improvement over SATA.

*IOEDC/IOECC on SATA (writes only), IOEDC/IOECC on SAS (both reads and writes)
**Averaged from random/sequential, read/write activities with write cache off
--

I admit I have no clue why SAS version should be/is faster. I just
pass on things I found out. But I am interested in opinion if there is
any substance in this marketing material.

Kind regards,
Damjan
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs fragmentation

[Damjan Perenic]

On Tue, Aug 11, 2009 at 11:04 PM, Richard
Elling wrote:
> On Aug 11, 2009, at 7:39 AM, Ed Spencer wrote:
>
>> I suspect that if we 'rsync' one of these filesystems to a second
>> server/pool  that we would also see a performance increase equal to what
>> we see on the development server. (I don't know how zfs send a receive
>> work so I don't know if it would address this "Filesystem Entropy" or
>> specifically reorganize the files and directories). However, when we
>> created a testfs filesystem in the zfs pool on the production server,
>> and copied data to it, we saw the same performance as the other
>> filesystems, in the same pool.
>
> Directory walkers, like NetBackup or rsync, will not scale well as
> the number of files increases.  It doesn't matter what file system you
> use, the scalability will look more-or-less similar. For millions of files,
> ZFS send/receive works much better.  More details are in my paper.

It would be nice if ZFS had something similar to VxFS File Change Log.
This feature is very useful for incremental backups and other
directory walkers, providing they support FCL.

Damjan
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss