Dave
This helps:- http://defect.opensolaris.org/bz/page.cgi?id=fields.html
The most common thing you will see is "Duplicate". As different people
find the same problem at different times in different ways and when they searched database to see if it was "known"
they could not find a bug description that seems to match their
problem. I logged quite a few of these :-)
The other common state is "Incomplete" typically because the submitter
has not provided enough info. for the evaluator to evaluate it.
Oh and what other company would allow you to see this data? :-
http://defect.opensolaris.org/bz/reports.cgi (Old Charts is interesting)
Trevor
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
"
This will tell you the
"Responsible
Engineer Richard
Morris"
and when it was fixed
"Release Fixed , solaris_10u6(s10u6_01) (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
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
