Thanks, Trevor. I understand the RFE/CR distinction. What I don't
understand is how this is not a bug that should be fixed in all solaris
versions.
The related ID 6612830 says it was fixed in Sol 10 U6, which was a while
ago. I am using OpenSolaris, so I would really appreciate confirmation
that it has been fixed in OpenSolaris as well. I can't tell by the info
on the bugs DB - it seems like it hasn't been fixed in OpenSolaris. If
it has, then the status should reflect it as Fixed/Closed in the bug
database...
--
Dave
Trevor Pretty wrote:
Dave
Yep that's an RFE. (Request For Enchantment) that's how things are
reported to engineers to fix things inside Sun. If it's an honest to
goodness CR = bug (However it normally need a real support paying
customer to have a problem to go from RFE to CR) the "responsible
engineer" evaluates it, and eventually gets it fixed, or not. When I
worked at Sun I logged a lot of RFEs, only a few where accepted as bugs
and fixed.
Click on the "new Search" link and look at the type and state menus. It
gives you an idea of the states a RFE and CR goes through. It's probably
documented somewhere, but I can't find it. Part of the joy of Sun
putting out in public something most other vendors would not dream of doing.
Oh and it doesn't help both RFEs and CR are labelled "bug" at
http://bugs.opensolaris.org/
So. Looking at your RFE.
It tells you which version on Nevada it was reported against
(translating this into an Opensolaris version is easy - NOT!)
Look at "*Related Bugs* 6612830
<http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=e49afb42be7df0f5f17ec9c2d711?bug_id=6612830>
"
This will tell you the
"*Responsible Engineer* Richard Morris"
and when it was fixed
"*Release Fixed* , solaris_10u6(s10u6_01) (*Bug ID:*2160894
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=2160894>) "
Although as nothing in life is guaranteed it looks like another bug
2160894 has been identified and that's not yet on bugs.opensolaris.org
Hope that helps.
Trevor
Dave wrote:
Just to make sure we're looking at the same thing:
http://bugs.opensolaris.org/view_bug.do?bug_id=6761786
This is not an issue of auto snapshots. If I have a ZFS server that
exports 300 zvols via iSCSI and I have daily snapshots retained for 14
days, that is a total of 4200 snapshots. According to the link/bug
report above it will take roughly 5.5 hours to import my pool (even when
the pool is operating perfectly fine and is not degraded or faulted).
This is obviously unacceptable to anyone in an HA environment. Hopefully
someone close to the issue can clarify.
--
Dave
Blake wrote:
I think the value of auto-snapshotting zvols is debatable. At least,
there are not many folks who need to do this.
What I'd rather see is a default property of 'auto-snapshot=off' for zvols.
Blake
On Thu, Aug 27, 2009 at 4:29 PM, Tim Cook<t...@cook.ms> wrote:
On Thu, Aug 27, 2009 at 3:24 PM, Remco Lengers <re...@lengers.com> wrote:
Dave,
Its logged as an RFE (Request for Enhancement) not as a CR (bug).
The status is 3-Accepted/ P1 RFE
RFE's are generally looked at in a much different way then a CR.
..Remco
Seriously? It's considered "works as designed" for a system to take 5+
hours to boot? Wow.
--Tim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
*/
*//*
*//*///*
www.eagle.co.nz <http://www.eagle.co.nz/>
This email is confidential and may be legally privileged. If received in
error please destroy and immediately notify us.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
