You may wish to look at this thread:
http://opensolaris.org/jive/thread.jspa?threadID=128046&tstart=0 (last
post):
---- start quote from thread ----
Hi everybody,
after looking into the current on source code (b134) into
/usr/src/lib/libstmf/common/store.c, I don't think that this bug
does still have an impact on COMSTAR.
The code there chunks the "provider_data_prop" (thats the stuff that
can get longer than 4kb) into several separate properties
"provider_data_prop-<N>" with 4kb length, when it stores it and
reads it back by the same algorithm.
If this would still be an issue (or ever was), you would not be able
to reboot your machine without loosing your data, since libstmf
will read the data after reboot from libscf again.
"svccfg export -a stmf" will only dump what libstmf has put into
it before.
So as far as I can say this warning in connection to COMSTAR is simply
wrong and not true anymore.
----end quote from thread ----
Josh Simon
On 06/29/2010 08:10 AM, Preston Connors wrote:
On Tue, 2010-06-29 at 08:58 +0200, Bruno Sousa wrote:
Hmm...that easy? ;)
Thanks for the tip, i will see if that works out.
Bruno
Be aware of the Important Note in
http://wikis.sun.com/display/OpenSolarisInfo/Backing+Up+and+Restoring+a
+COMSTAR+Configuration regarding Backing Up and Restoring a COMSTAR
Configuration.
Important Note
An existing bug in svccfg export causes data to be lost on export when
the persistent logical unit data (stored in the provider_data_pg_sbd
property group) exceeds 2 Kbytes. Refer to CR 6694511 for more details.
Because the truncation is silent, you cannot determine when data has
been lost on export. Until CR 6694511 is integrated, do not use the
instructions on this page to back up the STMF service.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
