Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
SMB/CIFS Statistics
1.2. Name of Document Author/Supplier:
Author: Jose B
What's missing is an interface table. I think though that based on the
statement that its not to be parsed ("for humans only"), the output is
not-an-interface.
- Garrett
On 04/ 7/10 05:51 PM, Jordan Brown wrote:
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is C
Garrett D'Amore wrote:
What's missing is an interface table. I think though that based on
the statement that its not to be parsed ("for humans only"), the
output is not-an-interface.
Yes. The stability is the same as the existing command:
|_|
On 04/ 7/10 10:47 PM, Jordan Brown wrote:
Garrett D'Amore wrote:
What's missing is an interface table. I think though that based on
the statement that its not to be parsed ("for humans only"), the
output is not-an-interface.
Yes. The stability is the same as the existing command:
|__
Garrett D'Amore wrote:
You haven't mentioned anything about underlying kstats. Is this how
these stats are implemented? Should that be covered under an ARC case
as well (perhaps this one)?
Jose is really the one to answer that, but as I'm here at the moment and
he's presumably not, I'll tak
From: Jordan Brown [mailto:jordan.br...@oracle.com]
Sent: Thursday, April 08, 2010 12:24 AM
To: Garrett D'Amore
Cc: psarc-...@sun.com; smb-eng...@oracle.com
Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout 04/14/2010]
Garrett D'Amore wrote:
You haven&#
On 04/ 8/10 12:07 AM, Jose Borrego wrote:
*From:* Jordan Brown [mailto:jordan.br...@oracle.com]
*Sent:* Thursday, April 08, 2010 12:24 AM
*To:* Garrett D'Amore
*Cc:* psarc-...@sun.com; smb-eng...@oracle.com
*Subject:* Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
04/14
On Thu, Apr 08, 2010 at 06:07:53AM -0700, Garrett D'Amore wrote:
> It would be a good idea to list out the kstats in this case, and
> perhaps declare them Project Private if you don't want to commit to
> supporting them for 3rd party apps.
kstats are scriptable (you can get at them from C, Perl5,
On Wed, Apr 7, 2010 at 5:51 PM, Jordan Brown wrote:
> long list of stats...
I'm running OpenSolaris.recent on my server @home with CIFS, Mac's and
PC's. File write access from the clients is slow; it appears that
something is timing out (not responding) for every initial save-file
request - whic
On Thu, Apr 08, 2010 at 10:36:15AM -0700, John Plocher wrote:
> I presume it is a good thing to have so many stats, and to be able to
> inundate the admin with tons of info, but what is missing for me is
> the conceptual structure to interpret and utilize all this info and to
> actually debug probl
Garrett D'Amore wrote:
> It would be a good idea to list out the kstats in this case, and perhaps
> declare them Project Private if you don't want to commit to supporting them
> for 3rd party apps.
I'll add that.
- Jose
___
opensolaris-arc mailing li
> -Original Message-
> From: Alan Wright [mailto:alan.wri...@oracle.com]
> Sent: Thursday, April 08, 2010 12:38 PM
> To: Garrett D'Amore
> Cc: psarc-...@sun.com; smb-eng...@oracle.com
> Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
> 04/14
e at least).
- Garrett
On 04/ 8/10 02:11 PM, Jose Borrego wrote:
-Original Message-
From: Alan Wright [mailto:alan.wri...@oracle.com]
Sent: Thursday, April 08, 2010 12:38 PM
To: Garrett D'Amore
Cc: psarc-...@sun.com; smb-eng...@oracle.com
Subject: Re: SMB/CIFS Statistics [PSARC/201
On 08/04/2010 18:36, John Plocher wrote:
I presume it is a good thing to have so many stats, and to be able to
inundate the admin with tons of info, but what is missing for me is
the conceptual structure to interpret and utilize all this info and to
actually debug problems. In ARC-speak, what (w
April 08, 2010 12:38 PM
>>> To: Garrett D'Amore
>>> Cc: psarc-...@sun.com; smb-eng...@oracle.com
>>> Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
>>> 04/14/2010]
>>>
>>> On 04/ 7/10 10:59 PM, Garrett D'Amore wr
On 04/ 7/10 10:59 PM, Garrett D'Amore wrote:
> On 04/ 7/10 10:47 PM, Jordan Brown wrote:
>> Garrett D'Amore wrote:
>>>
>>> What's missing is an interface table. I think though that based on
>>> the statement that its not to be parsed ("for humans only"), the
>>> output is not-an-interface.
>>
>> Y
On 04/08/10 15:48, Garrett D'Amore wrote:
I'd still like a record of the kstats in this case, albeit with Project
Private (or Uncommitted) binding.
Why bother for Project Private interfaces? Because in this case the
kstats are quite visible to end users (as are all kstats) via kstat(1M),
and so
11 PM, Jose Borrego wrote:
-Original Message-
From: Alan Wright [mailto:alan.wri...@oracle.com]
Sent: Thursday, April 08, 2010 12:38 PM
To: Garrett D'Amore
Cc: psarc-...@sun.com; smb-eng...@oracle.com
Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
04/14/2010]
On 04/ 7/10 1
racle.com]
Sent: Thursday, April 08, 2010 12:38 PM
To: Garrett D'Amore
Cc: psarc-...@sun.com; smb-eng...@oracle.com
Subject: Re: SMB/CIFS Statistics [PSARC/2010/120 FastTrack timeout
04/14/2010]
On 04/ 7/10 10:59 PM, Garrett D'Amore wrote:
> On 04/ 7/10 10:47 PM, Jordan Brown wrote:
&g
On 04/09/10 04:01, Alan Wright wrote:
> On 04/ 8/10 03:48 PM, Garrett D'Amore wrote:
>> So while the list isn't *required*, it *is* desired (by me at least).
>
> I'm struggling to see the desire for this case to provide that
> documentation. This case is documenting a change in smbstat output.
>
On Fri, Apr 9, 2010 at 7:51 AM, James Carlson wrote:
> On 04/09/10 04:01, Alan Wright wrote:
>> On 04/ 8/10 03:48 PM, Garrett D'Amore wrote:
>>> So while the list isn't *required*, it *is* desired (by me at least).
>>
>> I'm struggling to see the desire for this case to provide that
>> documentati
It appears that smb-eng...@oracle.com doesn't get the messages that
originate outside the company. We'll have to figure out how to address
that, but in the meantime those who are interested might want to review
the message log at
http://sac.sfbay/PSARC/2010/120/mail
___
Alan Wright wrote:
I honestly can't see what value a list would add to this case.
I agree. Note also that some have held that once you have put a Project
Private interface into an ARC case, you must run an ARC case to make any
changes to it. That seems like inappropriate overhead and a good
On 04/ 9/10 05:51 AM, James Carlson wrote:
On 04/09/10 04:01, Alan Wright wrote:
On 04/ 8/10 03:48 PM, Garrett D'Amore wrote:
So while the list isn't *required*, it *is* desired (by me at least).
I'm struggling to see the desire for this case to provide that
documentation. This case is docum
I think you should file changes, but can do so with a self-review case or even
just an email update to the original case. So not free, but really cheap.
-- Garrett
Jordan Brown wrote:
>Alan Wright wrote:
>> I honestly can't see what value a list would add to this case.
>
>I agree. Note al
On 04/10/10 09:56, Garrett D'Amore wrote:
> I think you should file changes, but can do so with a self-review case or
> even just an email update to the original case. So not free, but really
> cheap.
>
> -- Garrett
What the ARC Interface Taxonomy actually says about Project Private is this:
On 04/09/10 20:44, Alan Wright wrote:
> I honestly can't see what value a list would add to this case.
> The examples in the case material provide way more information
> than such a list because they provide context, and one can
> always obtain a list by running kstat at the command line.
>
> If an
On 04/11/10 08:59, Brian Utterback wrote:
On 04/09/10 20:44, Alan Wright wrote:
I honestly can't see what value a list would add to this case.
The examples in the case material provide way more information
than such a list because they provide context, and one can
always obtain a list by running
I tried, while there was some positive response, it was mostly summed
up as 'that's useless, stupid, a waste of time, don't bother, that's
what ARC cases are for, so it shouldn't be in code, etc.'.
...and the whole reason I was even trying to do that was just to
address concerns about another proj
On 04/ 9/10 05:47 PM, Jordan Brown wrote:
Alan Wright wrote:
I honestly can't see what value a list would add to this case.
I agree. Note also that some have held that once you have put a
Project Private interface into an ARC case, you must run an ARC case
to make any changes to it. That s
Garrett D'Amore wrote:
I have to admit, I don't understand the resistance to just posting the
list...
Reasons why I would resist...
1) The more you document, the more you're tied down.
2) The attitude that something might be construed to be public if it
isn't explicitly private is a worris
On 04/10/10 15:59, Brian Utterback wrote:
Unless and until we get a standard set of docs that definitively lists
what is public, then in proposals like this one is the only place these
interfaces are documented. You don't have to do this now, when you
integrate make a list from the kstat output
On 04/12/10 08:25 AM, Garrett D'Amore wrote:
On 04/ 9/10 05:47 PM, Jordan Brown wrote:
Alan Wright wrote:
I honestly can't see what value a list would add to this case.
I agree. Note also that some have held that once you have put a
Project Private interface into an ARC case, you must run an
On 04/12/10 02:15 PM, Alan Wright wrote:
Thanks for the +1.
My main concern is that smbstat is a consumer and using a consumer
as a vehicle for documenting a consumed interface doesn't seem
appropriate - both as a mechanism and for traceability. I'd really
prefer that this case remain a simple
This case timed out today. It has its +1, and the issue raised
(documentation of the underlying kstats) appears to have been resolved
as not being appropriate for this case. I expected it to come up at the
meeting today, but it seems there was no meeting, so I'm declaring it
closed approved.
35 matches
Mail list logo
