This is not the appropriate group/list for this message.
Crossposting to zfs-discuss (where it perhaps primarily
belongs) and to cifs-discuss, which also relates.
> Hi,
>
> I have an I/O load issue and after days of searching
> wanted to know if anyone has pointers on how to
> approach this.
>
>
[...]
> network overhead. The
> only question being if there's some precedent in
> another implementation
> for what the API should look like. I'm having
> trouble thinking up a
> likely google/bing query for that...
In attempting to find a precedent (without luck so far, and
I'll probably run o
[...]
> It seems a shame to me that the architecture for this
> new feature stops
> at the IP/driver connection and doesn't include the
> API level.
>
> --
> James Carlson 42.703N 71.076W
>
Particularly since the information is already available - the UD MTU
has to be already kn
[...]
> Disclaimer: I'm no network guru, and this is the
> first time I've so much
> as looked at RFCs 4391 and 4755. I have no idea what
> other
> implementations supporting IPoIB-CM do (it might be
> worth finding
> out...).
Ok, I looked (minimally), and I _think_ Linux is generally
allowing th
> Erik Nordmark wrote:
> >
> >> > Perhaps I didn't see it, but which (if either)
> MTU corresponds
> >> > to what may be publically seen? Or does it
> matter (if IP
> >> > fragmenting hides the distinction)?
> >
> > IP fragmentation hides the distinction.
> >
> > It is the unicast MTU that is r
Perhaps I didn't see it, but which (if either) MTU corresponds
to what may be publically seen? Or does it matter (if IP
fragmenting hides the distinction)?
--
This message posted from opensolaris.org
___
opensolaris-arc mailing list
opensolaris-arc@open
> Richard L. Hamilton wrote:
> > Beware that if you have getprogname(), you may find
> people wanting
> > the entire FreeBSD err(3) family,
>
> Already there:
>
> changeset: 4891:f4f971e9574d
> user:vk199839
> date:Sat Aug 18 10:07:23 2007 -
re getprogname(): since I don't see man pages in the public case
directory,
* is there also a setprogname() as in at least some FreeBSD? If so,
is it implicit in the run-time startup, or does one need to call it explicitly?
* since argv[0] can be anything, is this equivalent to getexecname()
(w
What SUSv4 functions are still missing after this case?
Have requests been filed for them? As an example, I didn't
see wcsnlen().
--
This message posted from opensolaris.org
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
> On 07/26/10 09:32 AM, Peter Memishian wrote:
> >
> > > Seeing yet another involvement of /etc/
> symlinks brought by Darren leads
> > > me to question the architectural value of the
> proposed changes.
> > > I like cleanlyness. I also like
> compatibility. This seems architecturally
>
> On 7/26/10 12:10 PM, Antonello Cruz wrote:
>
> > Well, your second email came just when I had
> finished my reply. Since it
> > is not immediately clear why I am restricting
> access to the files in
> > /etc/logadm.d I'll send my original reply here
> anyway.
> >
> > logadm can run arbitrary scr
[...]
> I'm not saying don't do it; I'm saying I'd want (a) a
> _very_ careful reading
> of standards to see if extensions are allowed, given
> such behavior; and
[...]
Just looked it up at
http://www.opengroup.org/onlinepubs/9699919799/utilities/expr.html
which says:
"The use of string arguments
Using the older behavior of expr vs the new (as seen in /usr/gnu/bin/expr)
(both of these SPARC snv_97, but that's irrelevant to my point):
$ x="index"
$ /usr/bin/expr "$x" = "i="
0
$ /usr/gnu/bin/expr "$x" = "i="
1
In other words, because commands called from the shell have no way to
kno
[...]
> There may or may not be customer scripts reading the
> files in this case,
> but I don't know of anything specific and any modern
> version of sendmail
> should not, at least.
>
> Hugh.
FYI, a number of Linux distros (and Mac OS X!) follow the
earlier Solaris model of persistently stori
> On 6/18/10 9:52 PM, Cynthia McGuire wrote:
> >
> > Template Version: @(#)sac_nextcase 1.70 03/30/10
> SMI
> > This information is Copyright (c) 2010, Oracle
> and/or its affiliates. All rights reserved.
>
> Seem to be missing some content here ... did you
> perhaps forget to
> forward something
> > Nevertheless, if there are _any_ scripts that use
> it, unless you get
> > rid of all 29 (or however many) links to it, I
> don't see any incremental gain
> > by removing some of them.
>
> Am taking the conservative approach here by removing
> only those
> commands which could not possibly ret
> On Tue, 2010-06-08 at 13:03 -0700, Scott Rotondo
> wrote:
> > Several people have pointed out that the harm from
> removing these
> > commands isn't that great because
> >
> > (a) recent scripts tend not to use this mechanism
> to figure out the type
> > of platform, and
> >
> > (b) older scr
[...]
> length strings like gecos etc.). NIS currently still
> has a 4k buffer
> max, so
> a NIS passwd entry total length has that upwards
> boundary. Also we do
> impose
> another max buffer size at 128K, such as when you do
> a getpwnam_r or
> similar API call and are using caching (nscd).
> While this case was approved, with the idea that
> these utilities would
> be replaced by integrating the GNU plotutils suite,
> I'd like to change
> direction somewhat.
>
> Specifically, it seems that /contrib is a superior
> delivery mechanism
> for these tools. I don't believe that there
[...]
> Therefore, mounts within a non-global zone are
> restricted to a
> given allowed list of filesystems, as described
> in Section 5 and
> Section 6. This applies to all mounts not just
> lofi ones.
> 5. New vfs flag VSW_ZMOUNT
>
> The default list of allowed filesystems is based
> upon a
> Is the implementation of hsfs therefore known to be
> robust
> against kernel crashes due to a corrupted filesystem,
> or is it simply
> that the demand is so high for lofi plus hsfs? What
> about udfs - if
> one wants to use CD images, presumably one might want
> do use DVD-ROM
> images as well
[...]
> Allowing lofi devices into non-global zones
> introduces a security
> issue. Some filesystems (notably UFS) are not
> sufficiently protected
> against corrupted or maliciously constructed
> filesystem images,
> which lofi allows the zone root user to modify.
> This could
> potentially l
> su - $USER -c "/usr/bin/audioctl (args)"
Double quotes around $USER, please. And I hope
that the contents of $USER are trustworthy at that point.
--
This message posted from opensolaris.org
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris
> as an exercise for yourself, consider how a new
> protocol
> such as RDP (Reliable Datagram Protocl) or ICMP
> would
> be mapped into dtrace using what you're introducing
> as
> the basis of a design for them.
I would think SCTP would be an even more interesting exercise,
since it probably
24 matches
Mail list logo
