zfs discuss - Jan 2010 - New ZFS Intent Log (ZIL) device available - Beta program now open!

The DDRdrive X1 OpenSolaris device driver is now complete,
please join us in our first-ever ZFS Intent Log (ZIL) beta test 
program.  A select number of X1s are available for loan,
preferred candidates would have a validation background 
and/or a true passion for torturing new hardware/driver :-)

We are singularly focused on the ZIL device market, so a test
environment bound by synchronous writes is required.  The
beta program will provide extensive technical support and a
unique opportunity to have direct interaction with the product
designers.

Would you like to take part in the advancement of Open
Storage and explore the far-reaching potential of ZFS
based Hybrid Storage Pools?

If so, please send an inquiry to "zfs at ddrdrive dot com".

The drive for speed,

Christopher George
Founder/CTO
www.ddrdrive.com

*** Special thanks goes out to SUN employees Garrett D''Amore and
James McPherson for their exemplary help and support.  Well done!
-- 
This message posted from opensolaris.org

Hey Chris,
> The DDRdrive X1 OpenSolaris device driver is now complete,
> please join us in our first-ever ZFS Intent Log (ZIL) beta test 
> program.  A select number of X1s are available for loan,
> preferred candidates would have a validation background 
> and/or a true passion for torturing new hardware/driver :-)
> 
> We are singularly focused on the ZIL device market, so a test
> environment bound by synchronous writes is required.  The
> beta program will provide extensive technical support and a
> unique opportunity to have direct interaction with the product
> designers.
Congratulations! This is great news for ZFS. I''ll be very interested to
see the results members of the community can get with your device as part
of their pool. COMSTAR iSCSI performance should be dramatically improved
in particular.

Adam

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Hi Adam,

So was FW aware of this or in contact with these guys?
Also are you requesting/ordering any of these cards to evaluate?

The device seems kind of small at 4GB, and uses a double wide PCI Express slot.

Neil.

On 01/13/10 12:27, Adam Leventhal wrote:
> Hey Chris,
> 
>> The DDRdrive X1 OpenSolaris device driver is now complete,
>> please join us in our first-ever ZFS Intent Log (ZIL) beta test 
>> program.  A select number of X1s are available for loan,
>> preferred candidates would have a validation background 
>> and/or a true passion for torturing new hardware/driver :-)
>>
>> We are singularly focused on the ZIL device market, so a test
>> environment bound by synchronous writes is required.  The
>> beta program will provide extensive technical support and a
>> unique opportunity to have direct interaction with the product
>> designers.
> 
> Congratulations! This is great news for ZFS. I''ll be very
interested to
> see the results members of the community can get with your device as part
> of their pool. COMSTAR iSCSI performance should be dramatically improved
> in particular.
> 
> Adam
> 
> --
> Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

That''s very interesting tech you''ve got there... :-) I have a
couple of
questions, with apologies in advance if I missed them on the website..

I see the PCI card has an external power connector - can you explain 
how/why that''s required, as opposed to using an on card battery or 
similar. What happens if the power to the card fails?

The 155mb rate for sustained writes is low for DDR ram? Is this because 
the backup to NAND is a constant thing, rather than only at power fail?

Regards
    Tristan

Christopher George wrote:
> The DDRdrive X1 OpenSolaris device driver is now complete,
> please join us in our first-ever ZFS Intent Log (ZIL) beta test 
> program.  A select number of X1s are available for loan,
> preferred candidates would have a validation background 
> and/or a true passion for torturing new hardware/driver :-)
>
> We are singularly focused on the ZIL device market, so a test
> environment bound by synchronous writes is required.  The
> beta program will provide extensive technical support and a
> unique opportunity to have direct interaction with the product
> designers.
>
> Would you like to take part in the advancement of Open
> Storage and explore the far-reaching potential of ZFS
> based Hybrid Storage Pools?
>
> If so, please send an inquiry to "zfs at ddrdrive dot com".
>
> The drive for speed,
>
> Christopher George
> Founder/CTO
> www.ddrdrive.com
>
> *** Special thanks goes out to SUN employees Garrett D''Amore and
> James McPherson for their exemplary help and support.  Well done!
>

Excellent questions!
> I see the PCI card has an external power connector - can you explain 
> how/why that''s required, as opposed to using an on card battery or
> similar. 
DDRdrive X1 ZIL functionality is best served with an external attached UPS,
this allows the X1 to perform as a non-volatile storage device without specific
user configuration or unique operation.  An often overlooked aspect of batteries
(irrespective of technology or internal/external) is their limited lifetime and
varying degrees of maintenance and oversight required.  For example, a
lithium (Li-Ion) battery supply, as used by older NVRAM products and not the
X1, does have the minimum required energy density for an internal solution.
But has a fatal flaw for enterprise applications - an ignition mode failure
possibility.  Google "lithium battery fire".  Such an instance, even
if rare,
would be catastrophic not only to the on-card data but the host server and so
on...  Supercapacitors are another alternative which thankfully do not share
the ignition mode failure mechanism of Li-Ion, but are hampered mainly by
cost with some longevity concerns which can be addressed.  In the end, we
selected data integrity, cost, and serviceability as our top three priorities.
This led us to the industry standard external lead-acid battery as sold by APC.

Key benefits of the DDRdrive X1 power solution:

1)  Data Integrity - Supports multiple back-to-back power failures, a single
DDRdrive X1 uses less than 5W when the host is powered down, even a
small UPS is over-provisioned and unlike an internal solution will not normally
require a lengthy recharge time prior to the next power incident.  Optionally a
backup to NAND can be performed to remove the UPS duration as a factor.

2)  Cost Effective / Flexible - The Smart-UPS SC 450VA (280 Watts) is an
excellent choice for most installations and retails for approximately $150.00.
Flexibility is in regard to UPS selection, as it can be right-sized (duration)
for
each individual application if needed.

3)  Reliability / Maintenance - UPS front panel LED status for battery 
replacement and audible alarms when battery is low or non-operational. 
Industry standard battery form factor backed by APC the industry leading 
manufacture of enterprise-class backup solutions.
> What happens if the *host* power to the card fails?
Nothing, the DDRdrive X1''s data integrity is guaranteed by the attached
UPS.
> The 155mb rate for sustained writes is low for DDR ram?
The DRAM''s value add is it''s extremely low latency (even
compared to NAND)
and other intrinsic properties such as longevity and reliability.  The
read/write
sequential bandwidth is completely bound by the PCI Express interface.
> Is this because the backup to NAND is a constant thing, rather than only
> at power fail?
No, the backup to NAND is not continual.  All Host IO is directed to DRAM for
maximum performance while the NAND only provides an optional (user
configured) backup/restore feature.

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

>>>>> "cg" == Christopher George <cgeorge at
ddrdrive.com> writes:
    cg> Nothing, the DDRdrive X1''s data integrity is guaranteed by
the
    cg> attached UPS.

I''ve found UPS power is less reliable than unprotected line power
where I live, especially when using bargain UPS''s like the ones you
suggest.  I''ve tracked it for five years, and that''s simply
the case.
When devices have dual power inputs I do plug one into the UPS though.

I''ve also found unplanned powerdowns usually occur during maintenance
because of people tripping over cords (networking equipment likes to
put A/B power on opposite sides of the chassis.  Thanks for that, to
those who do it.), dropping things, bumping power strip switches
(which should not exist in the first place), provoking crappy devices
(ex poweron surges causing overcurrent), mucking around with the
batteries, or confusing highly-stupid UPS microcontrollers over their
buggy web interfaces (``reset controller''''), clumsy buttonpads
(a
single on/off/test button?  are you *CRAZY*?  and sometimes I have to
_hold the button down_?  What next, double-pressing?  there''s on,
there''s off, but what about the ``off-but-charging''''
state: how''s it
requested and how''s it confirmed?  hazily?  thanks, assholes.).  Your
decision to use UPS power is based on the imaginary scenario you walk
us through: building loses line power for X minutes, UPS runs out.
Obviously I''m familiar with the scenario but honestly I''ve not
run
into that one in practice as often as other ones, which is why I call
it fantasy.

    cg> NAND only provides an optional (user configured)
    cg> backup/restore feature.

so, it does not even attempt to query the UPS?  How can it live up to
the ideally-functioning-UPS protection scheme you describe, then?  To
do so it needs UPS communication: it''d need to NAND-backup before the
battery ran out, so it needs to get advance warning of a low battery
from the UPS.  It''d also need a way to halt the computer, or at least
to take itself offline and propogate the error up the driver stack, if
the UPS has not enough charge to complete a NAND backup or of the UPS
considers its batteries defective.

Personally, I don''t care if the card talks to the UPS, because I think
realistically if you take the cases when power stops coming out of a
UPS and overlap them with the cases when the UPS provided warning
before the power stopped coming out, there''s not much overlap.
Spurious warnings and sudden shutdowns are *more* common over the life
of the units I''ve had than this imaginary graceful powerdown scenario.

Finally, data that''s stored ``durably'''' needs to
survive yanked
cables.  IMHO most people who are certain cables will never be yanked
or are willing to take the risk, would be better off just disabling
the ZIL rather than using a slog.  Then you don''t have to worry about
pools failing to import from missing slog if you do yank a cable,
which is a better tradeoff.

NAND storage therefore needs to be self-contained, like a disk drive,
to be useful as a slog.  The ANS-9010 comes closer to that than this
card, though I don''t know if it actually delivers, either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100114/8e530fcb/attachment.bin>

Thanks for the detailed response - further questions inline...

Christopher George wrote:
> Excellent questions!
>
>   
>> I see the PCI card has an external power connector - can you explain 
>> how/why that''s required, as opposed to using an on card
battery or
>> similar. 
>>     
>
> DDRdrive X1 ZIL functionality is best served with an external attached UPS,
> this allows the X1 to perform as a non-volatile storage device without
specific
> user configuration or unique operation.  An often overlooked aspect of
batteries
> (irrespective of technology or internal/external) is their limited lifetime
and
> varying degrees of maintenance and oversight required.  For example, a
> lithium (Li-Ion) battery supply, as used by older NVRAM products and not
the
> X1, does have the minimum required energy density for an internal solution.
> But has a fatal flaw for enterprise applications - an ignition mode failure
> possibility.  Google "lithium battery fire".  Such an instance,
even if rare,
> would be catastrophic not only to the on-card data but the host server and
so
> on...  Supercapacitors are another alternative which thankfully do not
share
> the ignition mode failure mechanism of Li-Ion, but are hampered mainly by
> cost with some longevity concerns which can be addressed.  In the end, we
> selected data integrity, cost, and serviceability as our top three
priorities.
> This led us to the industry standard external lead-acid battery as sold by
APC.
>
> Key benefits of the DDRdrive X1 power solution:
>
> 1)  Data Integrity - Supports multiple back-to-back power failures, a
single
> DDRdrive X1 uses less than 5W when the host is powered down, even a
> small UPS is over-provisioned and unlike an internal solution will not
normally
> require a lengthy recharge time prior to the next power incident. 
Optionally a
> backup to NAND can be performed to remove the UPS duration as a factor.
>
> 2)  Cost Effective / Flexible - The Smart-UPS SC 450VA (280 Watts) is an
> excellent choice for most installations and retails for approximately
$150.00.
> Flexibility is in regard to UPS selection, as it can be right-sized
(duration) for
> each individual application if needed.
>
> 3)  Reliability / Maintenance - UPS front panel LED status for battery 
> replacement and audible alarms when battery is low or non-operational. 
> Industry standard battery form factor backed by APC the industry leading 
> manufacture of enterprise-class backup solutions.
>   
OK, I take your point about battery fires, however we''ve been using 
battery backed cards (of various types) in servers for a while now, and 
I think you might have over over-emphasized those risks, when compared 
to the operational complexity of maintaining a separate power circuit 
for my PCI cards! But then, I haven''t actually done the research on 
battery reliability either. :-)

I''m not sure about others on the list, but I have a dislike of AC power
bricks in my racks. Sometimes they''re unavoidable, but they''re
also
physically awkward - where do we put them? Using up space on a dedicated 
shelf? Cable tied to the rack itself? Hidden under the floor?

Is the state of the power input exposed to software in some way? In 
other terms, can I have a nagios check running on my server that 
triggers an alert if the power cable accidentally gets pulled out?
>   
>> What happens if the *host* power to the card fails?
>>     
>
> Nothing, the DDRdrive X1''s data integrity is guaranteed by the
attached UPS.
>   
OK, which means that the UPS must be separate to the UPS powering the 
server then.
>   
>> The 155mb rate for sustained writes is low for DDR ram?
>>     
>
> The DRAM''s value add is it''s extremely low latency (even
compared to NAND)
> and other intrinsic properties such as longevity and reliability.  The
read/write
> sequential bandwidth is completely bound by the PCI Express interface.
>   
Any plans on a pci-e multi-lane version then? All my servers are still 
Gig-E, and I''m not likely to see more than 100MB/sec of NFS traffic, 
however I''m sure there are plenty of NFS servers on 10G out there that 
will see quite a bit more than 155MB/sec for moderate amounts of time. I 
know we can put more than one of these cards in a server, but those 
slots are often taken up with other things!

I look forward to these being available in Australia  :-)

Thanks,
    Tristan


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100114/98bf2855/attachment.html>

> I''m not sure about others on the list, but I have a dislike of AC
power
> bricks in my racks.
I definitely empathize with your position concerning AC power bricks, but
until the perfect battery is created, and we are far from it, it comes down to
tradeoffs.  I personally believe the ignition risk, thermal wear-out, and the
inflexible proprietary nature of Li-Ion solutions simply outweigh the benefits
of internal or all inclusive mounting for enterprise bound NVRAM.
> Is the state of the power input exposed to software in some way? In
> other terms, can I have a nagios check running on my server that
> triggers an alert if the power cable accidentally gets pulled out?
Absolutely, the X1 monitors the external supply and can detect not only a
disconnect but any loss of power.  In all cases, the card throws an interrupt
so that the device driver (and ultimately user space) can be immediately
notified.  The X1 does not rely on external power until the host power drops
below a certain threshold, so attaching/detaching the external power cable
has no effect on data integrity as long as the host is powered on.
> OK, which means that the UPS must be separate to the UPS powering
> the server then.
Correct, a dedicated (in this case redundant) UPS is expected.
> Any plans on a pci-e multi-lane version then?
Not at this time.  In addition to the reduced power and thermal output, the
PCIe x1 connector has the added benefit of not competing with other
HBA''s
which do require a x4 or x8 PCIe connection.

Very appreciative of the feedback!

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

On Thu, Jan 14, 2010 at 12:35:32AM -0800, Christopher George
wrote:
> > I''m not sure about others on the list, but I have a dislike
of AC power
> > bricks in my racks.
> 
> I definitely empathize with your position concerning AC power bricks, but
> until the perfect battery is created, and we are far from it, it comes down
to
> tradeoffs.  I personally believe the ignition risk, thermal wear-out, and
the
> inflexible proprietary nature of Li-Ion solutions simply outweigh the
benefits
> of internal or all inclusive mounting for enterprise bound NVRAM.
Is there any data out there that have tracked these sort of ignition
incidents?  I have to admit I''d never heard of this.  We have quite a
few BBU backed RAID controllers in our servers and I''ve never had
anything remotely like this occur.  I know anecdotal evidence is
meaningless, but this definitely surprised me a little.

My gut tells me the risk of this is pretty low and most are going to
prefer the convenience of an onboard BBU to installing UPS''es in all
their racks (as good a practice as that may be).

Gut isn''t the best to go on of course, which is why I''m
interested in
seeing some statistics on this sorta thing...

Interesting product though!

Ray

On Thu, Jan 14, 2010 at 11:35 AM, Christopher George
<cgeorge at ddrdrive.com> wrote:
>> I''m not sure about others on the list, but I have a dislike of
AC power
>> bricks in my racks.
>
> I definitely empathize with your position concerning AC power bricks, but
> until the perfect battery is created, and we are far from it, it comes down
to
> tradeoffs. ?I personally believe the ignition risk, thermal wear-out, and
the
> inflexible proprietary nature of Li-Ion solutions simply outweigh the
benefits
> of internal or all inclusive mounting for enterprise bound NVRAM.
That''s kind of an overstatement. NVRAM backed by on-board LI-Ion
batteries has been used in storage industry for years; I can easily
point out a company that has shipped tens of thousands of such boards
over last 10 years.

Regards,
Andrey
>
>> Is the state of the power input exposed to software in some way? In
>> other terms, can I have a nagios check running on my server that
>> triggers an alert if the power cable accidentally gets pulled out?
>
> Absolutely, the X1 monitors the external supply and can detect not only a
> disconnect but any loss of power. ?In all cases, the card throws an
interrupt
> so that the device driver (and ultimately user space) can be immediately
> notified. ?The X1 does not rely on external power until the host power
drops
> below a certain threshold, so attaching/detaching the external power cable
> has no effect on data integrity as long as the host is powered on.
>
>> OK, which means that the UPS must be separate to the UPS powering
>> the server then.
>
> Correct, a dedicated (in this case redundant) UPS is expected.
>
>> Any plans on a pci-e multi-lane version then?
>
> Not at this time. ?In addition to the reduced power and thermal output, the
> PCIe x1 connector has the added benefit of not competing with other
HBA''s
> which do require a x4 or x8 PCIe connection.
>
> Very appreciative of the feedback!
>
> Christopher George
> Founder/CTO
> www.ddrdrive.com
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

On Thu, 14 Jan 2010, Ray Van Dolson wrote:
> My gut tells me the risk of this is pretty low and most are going to
> prefer the convenience of an onboard BBU to installing UPS''es in
all
> their racks (as good a practice as that may be).
Other than the spontaneous combustion issue (which was heavily covered 
by the press a couple of years ago, and resulted in many product 
recalls), it seems that the main advantage of using external power is 
to avoid needing to shut down the server and open the chassis if a 
battery goes bad.  Most servers are not designed to be serviced in 
this way while they remain running.

Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

> Is there any data out there that have tracked these sort of ignition
> incidents? I have to admit I''d never heard of this. We have quite
a
> few BBU backed RAID controllers in our servers and I''ve never had
> anything remotely like this occur. I know anecdotal evidence is
> meaningless, but this definitely surprised me a little.
I agree, it would be very informative if RAID HBA vendors would publish failure
statistics of their Li-Ion based BBU products.  
> My gut tells me the risk of this is pretty low and most are going to
> prefer the convenience of an onboard BBU to installing UPS''es in
all
> their racks (as good a practice as that may be).
Again I agree, I am not recommending, nor did I mean to allude, that to be the
proper and/or preferred solution for RAID controllers.  To my knowledge, the
mAh requirements of a DDRdrive X1 class product cannot be supported by
any of the BBUs currently found on RAID controllers.  It would require either a
substantial increase in energy density or a decrease in packaging volume
both of which incur additional risks.
> Interesting product though!
Thanks,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

> That''s kind of an overstatement. NVRAM backed by on-board LI-Ion
> batteries has been used in storage industry for years;
Respectfully, I stand by my three points of Li-Ion batteries as they relate
to enterprise class NVRAM: ignition risk, thermal wear-out, and
proprietary design.  As a prior post stated, there is a dearth of published
failure statistics of Li-Ion based BBUs.
> I can easily point out a company that has shipped tens of
> thousands of such boards over last 10 years.
No argument here, I would venture the risks for consumer based Li-Ion
based products did not become apparent or commonly accepted until
the user base grew several orders of magnitude greater than "tens of
thousands".

For the record, I agree there is a marked convenience with an integrated
high energy Li-Ion battery solution - but at what cost?

We chose an external solution because it is a proven and industry
standard method of enterprise class data backup.

Thanks,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

>>>>> "cg" == Christopher George <cgeorge at
ddrdrive.com> writes:
    cg> I agree, it would be very informative if RAID HBA vendors
    cg> would publish failure statistics of their Li-Ion based BBU
    cg> products.

If they haven''t, then on what are you basing your decision *not* to
use one?  Just the random thought that they might fail?

    cg> inflexible proprietary nature of Li-Ion

You can get complete systems with charging microcontroller and battery
without any undue encumbrances I can detect on sparkfun.com.  What''s
``proprietary'''' mean in this context?

    cg> the ignition risk, thermal wear-out, and the inflexible
    cg> proprietary nature of Li-Ion solutions simply outweigh the
    cg> benefits of internal or all inclusive mounting for enterprise
    cg> bound NVRAM.

well...for *HOME* use based on the failure modes I''ve observed
I''d
prefer to keep the battery next to the SDRAM like ACARD and LSI do.

for the enterprise, someone should warn netapp/hitachi/emc/storagetek
who are presumably Lion based nvram users.

One thing on which I can agree: if the vendor has used Lion it''s hard
to tell if the implementation is proper, ex whether it will warn of an
aged battery without enough capacity.  For slog, IMHO the ideal
behavior would be:

 1. weekly test-flushes to CF or USBstick or whatever is the NAND
    backing-store

 2. the device should shut itself off, as if SATA cable were pulled,
    or in some other way ZFS detects instantly, if the battery''s not
    got capacity left after the test flush completes.  One way would
    be to require *two* consecutive successful test flushes each week.

 3. there should be a button you can press to simulate the
    battery-failure-powerdown behavior, so you can test that ZFS and
    your controller respond properly.

 4. ``redundant'''' power should mean the device has (1) power
from
    host, and (2) enough stored energy in the battery to do two
    consecutive flushes.  Whenever the device does not have
    ``redundant'''' power, it should:

    a. disable itself as in (3)

    b. flush SDRAM to NAND.

    This means, if the device''s battery is exhausted, the system may
    boot with the device disconnected.  The host will have to suport
    hotplug so the slog can come back after the battery charges.

so, (2) is really a special case of (4).  

and AIUI Lion will last longer if you don''t charge it to 100%.
laptops usually want 100% because they compete on mAh/kg at initial
purchase, but for this application charging to 70% should be fine
which from what I heard will make them last a lot longer before
crystalizing.

    cg> can detect not only a disconnect but any loss of power.  In
    cg> all cases, the card throws an interrupt so that the device
    cg> driver (and ultimately user space) can be immediately
    cg> notified.

We need to look at the overall system, though.  Does a ZFS system
using the card disable the slog when this happens?  or does it just
print a warning in dmesg and do nothing?

When you''re using a LSI BBU, the disks behind the controller have
their write cahce disabled.  so, if you evil-tune ZFS to skip issuing
SYNC CACHE, but then the BBU dies and becomes write-through, the
overall system is still safe (albeit slow).

Also what you describe still doesn''t seem to detect the failure case
you brought up yourself, of a worn-out battery.  UPS''s do test their
batteries, but ones with worn-out batteries enter bypass mode, they
don''t turn themselves off, which seems to be the only way your card
would have to hear a warning.

    cg> attaching/detaching the external power cable has no effect on
    cg> data integrity as long as the host is powered on.

In other words, as long as you don''t trip over both cables at once.  :(

Does the device partially obey my (4) and immediately flush to NAND
when the host is powered off?  or does it keep the data in SDRAM only
for as long as possible, until told to do otherwise by ``the
user'''' or
something?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100114/55eda125/attachment.bin>

On Thu, Jan 14, 2010 at 10:02 PM, Christopher George
<cgeorge at ddrdrive.com> wrote:
>> That''s kind of an overstatement. NVRAM backed by on-board
LI-Ion
>> batteries has been used in storage industry for years;
>
> Respectfully, I stand by my three points of Li-Ion batteries as they relate
> to enterprise class NVRAM: ignition risk, thermal wear-out, and
> proprietary design. ?As a prior post stated, there is a dearth of published
> failure statistics of Li-Ion based BBUs.
Why not enlighten EMC/NTAP on this then?
>
>> I can easily point out a company that has shipped tens of
>> thousands of such boards over last 10 years.
>
> No argument here, I would venture the risks for consumer based Li-Ion
> based products did not become apparent or commonly accepted until
> the user base grew several orders of magnitude greater than "tens of
> thousands".
>
> For the record, I agree there is a marked convenience with an integrated
> high energy Li-Ion battery solution - but at what cost?
Um, with Li-Ion battery in each and every of a billions of cell phones
out there ...
>
> We chose an external solution because it is a proven and industry
> standard method of enterprise class data backup.
Could you please elaborate on the last statement, provided you meant
anything beyond "UPS is a power-backup standard"?

Regards,
Andrey
>
> Thanks,
>
> Christopher George
> Founder/CTO
> www.ddrdrive.com
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

On Thu, January 14, 2010 14:34, Miles Nordin wrote:
>>>>>> "cg" == Christopher George <cgeorge at
ddrdrive.com> writes:
>     cg> inflexible proprietary nature of Li-Ion
>
> You can get complete systems with charging microcontroller and battery
> without any undue encumbrances I can detect on sparkfun.com. 
What''s
> ``proprietary'''' mean in this context?
I''m pretty sure the insides of my camera batteries and such are
"standard
parts" at that level; but it doesn''t do me any good.  I
don''t know how to
find the sources for  those parts, be sure I''m right, and fake up
replacements.  (Also there are serviceability issues if I mess about
inside and later need manufacturer service.)  So I''m stuck paying for
expensive proprietary batteries.

When I look at something I''m buying for serious use, I consider that
sort
of thing.  If it doesn''t say something like "Takes a Foobar (or
equivalent) mumble-76-x3" (or if I can''t find sources for what it
says it
takes), that''s a point against it.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

> Why not enlighten EMC/NTAP on this then?
On the basic chemistry and possible failure characteristics of Li-Ion
batteries?

I will agree, if I had system level control as in either example, one could
definitely help mitigate said risks compared to selling a card based
product where I have very little control over the thermal envelopes I am
subjected.
> Could you please elaborate on the last statement, provided you meant
> anything beyond "UPS is a power-backup standard"?
Although, I do think the discourse is healthy and relevant.  At this point, I
am comfortable to agree to disagree.  I respect your point of view, and do
agree strongly that Li-Ion batteries play a critical and highly valued role in
many industries.

Thanks,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

On Jan 14, 2010, at 11:02 AM, Christopher George wrote:
>> That''s kind of an overstatement. NVRAM backed by on-board
LI-Ion
>> batteries has been used in storage industry for years;
> 
> Respectfully, I stand by my three points of Li-Ion batteries as they relate
> to enterprise class NVRAM: ignition risk, thermal wear-out, and
> proprietary design.  As a prior post stated, there is a dearth of published
> failure statistics of Li-Ion based BBUs.
> 
>> I can easily point out a company that has shipped tens of
>> thousands of such boards over last 10 years.
> 
> No argument here, I would venture the risks for consumer based Li-Ion
> based products did not become apparent or commonly accepted until
> the user base grew several orders of magnitude greater than "tens of
> thousands".
> 
> For the record, I agree there is a marked convenience with an integrated
> high energy Li-Ion battery solution - but at what cost?
I see nothing in the design that precludes a customer from using a
Li-Ion battery, if they so desire.  Perhaps the collective has forgotten
that DC power is one of the simplest and most widespread interfaces
around? :-)

So it boils down to packaging. I personally dislike having batteries
all over the place, and I''ve seen dozens of customers who never
pay attention to the battery status on their systems. However, for 
future design considerations, an optional internal energy mount 
can keep the wolves at bay.
 -- richard
> We chose an external solution because it is a proven and industry
> standard method of enterprise class data backup.
> 
> Thanks,
> 
> Christopher George
> Founder/CTO
> www.ddrdrive.com
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Very interesting product indeed!

Given the volume one of these cards take up inside the server though,
I couldn''t help but think that 4GB is a bit on the low side.

Alex.



On Wed, Jan 13, 2010 at 5:51 PM, Christopher George
<cgeorge at ddrdrive.com> wrote:
> The DDRdrive X1 OpenSolaris device driver is now complete,
> please join us in our first-ever ZFS Intent Log (ZIL) beta test
> program. ?A select number of X1s are available for loan,
> preferred candidates would have a validation background
> and/or a true passion for torturing new hardware/driver :-)
>
> We are singularly focused on the ZIL device market, so a test
> environment bound by synchronous writes is required. ?The
> beta program will provide extensive technical support and a
> unique opportunity to have direct interaction with the product
> designers.
>
> Would you like to take part in the advancement of Open
> Storage and explore the far-reaching potential of ZFS
> based Hybrid Storage Pools?
>
> If so, please send an inquiry to "zfs at ddrdrive dot com".
>
> The drive for speed,
>
> Christopher George
> Founder/CTO
> www.ddrdrive.com
>
> *** Special thanks goes out to SUN employees Garrett D''Amore and
> James McPherson for their exemplary help and support. ?Well done!
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

On Thu, Jan 14, 2010 at 5:22 PM, Richard Elling <richard.elling at
gmail.com>wrote:
> On Jan 14, 2010, at 11:02 AM, Christopher George wrote:
>
> >> That''s kind of an overstatement. NVRAM backed by on-board
LI-Ion
> >> batteries has been used in storage industry for years;
> >
> > Respectfully, I stand by my three points of Li-Ion batteries as they
> relate
> > to enterprise class NVRAM: ignition risk, thermal wear-out, and
> > proprietary design.  As a prior post stated, there is a dearth of
> published
> > failure statistics of Li-Ion based BBUs.
> >
> >> I can easily point out a company that has shipped tens of
> >> thousands of such boards over last 10 years.
> >
> > No argument here, I would venture the risks for consumer based Li-Ion
> > based products did not become apparent or commonly accepted until
> > the user base grew several orders of magnitude greater than "tens
of
> > thousands".
> >
> > For the record, I agree there is a marked convenience with an
integrated
> > high energy Li-Ion battery solution - but at what cost?
>
> I see nothing in the design that precludes a customer from using a
> Li-Ion battery, if they so desire.  Perhaps the collective has forgotten
> that DC power is one of the simplest and most widespread interfaces
> around? :-)
>
> So it boils down to packaging. I personally dislike having batteries
> all over the place, and I''ve seen dozens of customers who never
> pay attention to the battery status on their systems. However, for
> future design considerations, an optional internal energy mount
> can keep the wolves at bay.
>  -- richard
>
>
Personally I''d say it''s a must.  Most DC''s I operate
in wouldn''t tolerate
having a card separately wired from the chassis power.  It''s far, far,
far
more likely to have a tech knock that power cord out and not have anyone
notice than to have a battery spontaneously combust.   My .02.

-- 
--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100114/8dda4469/attachment.html>

>>>>> "dd" == David Dyer-Bennet <dd-b at
dd-b.net> writes:
    dd> I''m pretty sure the insides of my camera batteries and such
    dd> are "standard parts" at that level; but it doesn''t
do me any
    dd> good.  I don''t know how to find the sources for those parts,
    dd> be sure I''m right, and fake up replacements.  

the way how is to go to sparkfun.com where you can download schematics
and buy assembled reference designs for charging single-cell lipol
batteries, as well as the batteries themselves in a variety of sizes.
The schematic for the charger is given, and there''s no circuitry
inside the batteries.  HTH.

    dd> (Also there are serviceability issues if I mess about inside
    dd> and later need manufacturer service.)

what the?  I do not udnerstand.  yeah, if you make something yourself
in the garage, then you can still have manufacturer service, but you
are the manufacturer now so that would be self-service.  Are you
talking about your camera now or about the slog?  The idea was to have
Christopher''s company put the battery into their product, so there is
still just one manufacturer and no finger-pointing: the batteries are
not yet proprietary when you buy them at sparkfun.

    dd> So I''m stuck paying for expensive proprietary batteries.

for your camera, yes, got it.

what does that have to do with suggesting a battery belongs next to
the DRAM, not external, for an internal pcie slog?  The OP was
Christopher, saying he chose a batteryless design because lipol is
among other things ``proprietary'''', yet experimenters and
cheap
consumer electronics have been using it for almost a decade, and there
are cheapo charging chips from linear devices or microchip or whatever
that include experience-tested protocols for avoiding flames (yes
agreed writing your own charging software would be risky), and chinese
oem may well just design it for you.  I mean srsly I have friends
using these batteries and could probably put the battery on myself so
what sort of person am I paying to make this thing for me if
li-ion/lipol is this great scary proprietary deep-FUDpool mystery to
them?  so...you know...give us a real reason plz, not a
punt-and-blame-the-sysadmin design with no battery, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100114/13026acb/attachment.bin>

> I see nothing in the design that precludes a customer from using a
> Li-Ion battery, if they so desire. Perhaps the collective has forgotten
> that DC power is one of the simplest and most widespread interfaces
> around? :-)
Richard,

Very good point!  We have already had a request for the DC jack to be
unpopulated so that an internal power source could be utilized.  We will
make this modification available to any customer who asks.

Thanks,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

> Personally I''d say it''s a must.  Most DC''s I
operate in wouldn''t tolerate
> having a card separately wired from the chassis power.
May I ask the list, if this is a hard requirement for anyone else?

Please email me directly "cgeorge at ddrdrive dot com".

Thank you,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org

On Thu, Jan 14, 2010 at 5:07 PM, Christopher George
<cgeorge at ddrdrive.com> wrote:
>> Why not enlighten EMC/NTAP on this then?
>
> On the basic chemistry and possible failure characteristics of Li-Ion
> batteries?
>
> I will agree, if I had system level control as in either example, one could
> definitely help mitigate said risks compared to selling a card based
> product where I have very little control over the thermal envelopes I am
> subjected.
>
>> Could you please elaborate on the last statement, provided you meant
>> anything beyond "UPS is a power-backup standard"?
>
> Although, I do think the discourse is healthy and relevant. ?At this point,
I
> am comfortable to agree to disagree. ?I respect your point of view, and do
> agree strongly that Li-Ion batteries play a critical and highly valued role
in
> many industries.
>
> Thanks,
>
Congratulations Christopher - great product - and I''m sure that this
will be the first of a family of products for you!  Personally I like
the simplicity of the design and the lack of a battery to worry about.

This is a great addition to any ZFS installation ...   :)

Regards,

-- 
Al Hopper  Logical Approach Inc,Plano,TX al at logical-approach.com
                   Voice: 972.379.2133 Timezone: US CDT
OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007
http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/

On 1/13/10 9:51 AM, Christopher George wrote:
> The DDRdrive X1 OpenSolaris device driver is now complete,
> please join us in our first-ever ZFS Intent Log (ZIL) beta test
> program.  A select number of X1s are available for loan,
> preferred candidates would have a validation background
> and/or a true passion for torturing new hardware/driver :-)
>
> We are singularly focused on the ZIL device market, so a test
> environment bound by synchronous writes is required.  The
> beta program will provide extensive technical support and a
> unique opportunity to have direct interaction with the product
> designers.
>
> Would you like to take part in the advancement of Open
> Storage and explore the far-reaching potential of ZFS
> based Hybrid Storage Pools?
>
> If so, please send an inquiry to "zfs at ddrdrive dot com".
>
> The drive for speed,
>
> Christopher George
> Founder/CTO
> www.ddrdrive.com
>
> *** Special thanks goes out to SUN employees Garrett D''Amore and
> James McPherson for their exemplary help and support.  Well done!
I''d like to say thanks for putting a price point somewhere on your
website, so
many people with new products make the mistake of thinking it is important to 
withhold that info from potential customers.
I get vendors calling or wanting to meet without giving a price range.
I tell them - "We don''t have to meet - If it costs $15,000 I
don''t want any,
if it is $1,000 I''ll take one, if it is $100 I''ll take
12..."

On Fri, Jan 15, 2010 at 2:07 AM, Christopher George
<cgeorge at ddrdrive.com> wrote:
>> Why not enlighten EMC/NTAP on this then?
>
> On the basic chemistry and possible failure characteristics of Li-Ion
> batteries?
>
> I will agree, if I had system level control as in either example, one could
> definitely help mitigate said risks compared to selling a card based
> product where I have very little control over the thermal envelopes I am
> subjected.
>
>> Could you please elaborate on the last statement, provided you meant
>> anything beyond "UPS is a power-backup standard"?
>
> Although, I do think the discourse is healthy and relevant. ?At this point,
I
> am comfortable to agree to disagree. ?I respect your point of view, and do
Same on my side. I don''t object to your design decision, my objection
was to the negative advertisement wrt another design. Good luck with
beta and beyond.

Regards,
Andrey
> agree strongly that Li-Ion batteries play a critical and highly valued role
in
> many industries.
>
> Thanks,
>
> Christopher George
> Founder/CTO
> www.ddrdrive.com
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

>From the web page it looks like this is a card that goes into the computer
system. That''s not very useful for enterprise applications, as they are
going to want to use an external array that can be used by a redundant pair of
servers.
I''m very interested in a cost-effective device that will interface to
two systems.
-- 
This message posted from opensolaris.org

On Mon, Jan 18, 2010 at 8:48 PM, Charles Hedrick <hedrick at
rutgers.edu>wrote:
> From the web page it looks like this is a card that goes into the computer
> system. That''s not very useful for enterprise applications, as
they are
> going to want to use an external array that can be used by a redundant pair
> of servers.
>
> I''m very interested in a cost-effective device that will interface
to two
> systems.
>
>
That''s called an SSD in a SAS array.

-- 
--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100118/3501d709/attachment.html>

> From the web page it looks like this is a card that goes into the
> computer system.  That''s not very useful for enterprise
applications,
> as they are going to want to use an external array that can be used 
> by a redundant pair of servers.
The DDRdrive X1 does utilize a half-length/full-height/two-slot PCIe plug-in
card form factor.  So for systems such as the Sun Storage 7310/7410, we
are not a solution.  Sun does offer a Write Flash Accelerator (Logzilla) to
satisfy both single and clustered controller configurations.

Our intention is to provide enterprise customers (non-clustered) an
additional option.

Thanks,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org