Re: [OpenIndiana-discuss] DLNA/UPnP server for OI151a?
Is there some hello-world-starter-SFEspec-file or some SFE-for-the-really-retarded I could read to get me thru doing this? On 2011-10-17 04:09, openindiana-discuss-requ...@openindiana.org wrote: Message: 6 Date: Sun, 16 Oct 2011 15:46:46 -0400 From: Alex Viskovatoff To: Discussion list for OpenIndiana Subject: Re: [OpenIndiana-discuss] DLNA/UPnP server for OI151a? Message-ID:<1318794406.2220.16.camel@diotima.solaris> Content-Type: text/plain; charset="UTF-8" On Sun, 2011-10-16 at 18:43 +0200, Hans J. Albertsson wrote: > I'm running serviio 0.6.0.1 as a DLNA server on my Supermicro server > with OI151a, with very good results. > > I'm thinking of producing a pkg IPS package, and was wondering if there > is some sort of cheat sheet or simple example code for doing this. > > Serviiio is a java library, started from a shell script. > I'm currently running the linux version straight out of the box, > starting it manually. > It has absolutely no problem running in OI151a. > > I suppose the daemon should be a service in smf, and the "control > console" a command in /usr/bin. > The only dependency is a good enough java, and the proper ffmpeg. So it > ought to be easy. > > Is there some basic package example that could be easily modified to > provide an IPS serviio pkg in some repository? Hi Hans, An issue here is the dependency on ffmpeg. ffmpeg is not part of the OI core; it is supplied by oi-sfe. Since oi-sfe is an extras repository, it has been decided that packages in the OI core -- which are built with the native OI build system called oi-build -- should not depend on packages in oi-sfe. This means that if you wanted to package Serviio, you would have to create a pkgbuild spec for it, so that it could be incorporated into oi-sfe. Regards, Alex ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Software contributions for openindiana
Thank you, I will try to do that. Paolo Il 10/15/11 5:55 PM, Josef 'Jeff' Sipek ha scritto: On Fri, Oct 14, 2011 at 05:30:43PM +0200, Paolo Marcheschi wrote: Hi I would like to add a software for DICOM Medical images, "DCMTK is a collection of libraries and applications implementing large parts the DICOM standard" It works fine on the openindiana platform. I compiled the latest, correcting a simple error in one source. What is the procedure to have it included in a repository ? Cool! First things first, I would suggest that you join #oi-dev on IRC (on Freenode). The people there can you help with any issues you might have while building a package. We are making a unified build system for post-151 releases. Here are the instructions: http://wiki.openindiana.org/oi/Building+with+oi-build Jeff. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] XNV_174a and 175a
I just noticed an article on the OI wiki with instructions for building newer versions of X than the one included with oi_151a ( http://wiki.openindiana.org/oi/Building+XNV_174a+on+oi_151a). I'm a bit unclear on the contents because it alternately refers to both XNV_174a and XNV_175a. The latest version I see in the Mercurial repository is 174a, but the article mentions success building 175a and suggests updating to 175a for Sandy Bridge graphics support. Does this mean Sandy Bridge graphics are not supported by XNV_174a? I'm interested in a laptop that comes with Intel HD 3000 graphics and want to explore the possibility of getting it to work using the instructions in this article. Thanks, Ian Johnson ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] XNV_174a and 175a
Ian, Xnv_175a was the 'upstream' test build run on oi_151a. Xnv_174a is the current build in OI sustaining so the wiki reflects how to do the build using the Xnv sustaining repo for OI. The sustaining repos may be updated soon to reflect the latest upstream so this may longer be an issue. ~ Ken Mays From: Ian Johnson To: openindiana-discuss@openindiana.org Sent: Monday, October 17, 2011 8:30 AM Subject: [OpenIndiana-discuss] XNV_174a and 175a I just noticed an article on the OI wiki with instructions for building newer versions of X than the one included with oi_151a ( http://wiki.openindiana.org/oi/Building+XNV_174a+on+oi_151a). I'm a bit unclear on the contents because it alternately refers to both XNV_174a and XNV_175a. The latest version I see in the Mercurial repository is 174a, but the article mentions success building 175a and suggests updating to 175a for Sandy Bridge graphics support. Does this mean Sandy Bridge graphics are not supported by XNV_174a? I'm interested in a laptop that comes with Intel HD 3000 graphics and want to explore the possibility of getting it to work using the instructions in this article. Thanks, Ian Johnson ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] DLNA/UPnP server for OI151a?
* Hans J. Albertsson [2011-10-17 10:50]: > Is there some hello-world-starter-SFEspec-file or some > SFE-for-the-really-retarded I could read to get me thru doing this? pkgbuild specfiles are very similar to RPM specfiles so you may look at Redhat's RPM guide to get an idea on how they work. The differences and specifics of the pkgbuild specfile format are documented in http://pkgbuild.sourceforge.net/spec-files.txt A few introductory resources and reference documentation are on http://pkgbuild.sourceforge.net/man.php. Finally, looking at exisiting specfiles at http://hg.openindiana.org/upstream/spec-files-extra/ and http://hg.openindiana.org/upstream/oracle/spec-files/ might help quite a bit to get started. -- Guido Berhoerster ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] XNV_174a and 175a
On 10/17/11 05:30 AM, Ian Johnson wrote: I just noticed an article on the OI wiki with instructions for building newer versions of X than the one included with oi_151a ( http://wiki.openindiana.org/oi/Building+XNV_174a+on+oi_151a). I'm a bit unclear on the contents because it alternately refers to both XNV_174a and XNV_175a. The latest version I see in the Mercurial repository is 174a, but the article mentions success building 175a and suggests updating to 175a for Sandy Bridge graphics support. Does this mean Sandy Bridge graphics are not supported by XNV_174a? I'm interested in a laptop that comes with Intel HD 3000 graphics and want to explore the possibility of getting it to work using the instructions in this article. I don't think the intel driver in either 174a or 175a will be at all operable on the illumos kernel as it expects a kernel i915 module that supports Kernel Mode-Setting (KMS), which no one has ported to illumos yet (though I know of at least one person trying to). The differences between 174a & 175a have nothing to do with Intel graphics - they're simply unrelated bug fixes as you can see in the hg log: http://hg.openindiana.org/upstream/oracle/xnv/shortlog -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] XNV_174a and 175a
Thanks for the clarification. If Xnv_175a is the first version to support Sandy Bridge graphics, did you follow mostly the same build process for it as for 174a? I'd like to try building it from the upstream repo. Ian Johnson 2011/10/17 ken mays > Ian, > > Xnv_175a was the 'upstream' test build run on oi_151a. Xnv_174a is the > current build in OI sustaining so the wiki reflects how to do the build > using the Xnv sustaining repo for OI. > > > The sustaining repos may be updated soon to reflect the latest upstream so > this may longer be an issue. > > ~ Ken Mays > > > > > From: Ian Johnson > To: openindiana-discuss@openindiana.org > Sent: Monday, October 17, 2011 8:30 AM > Subject: [OpenIndiana-discuss] XNV_174a and 175a > > I just noticed an article on the OI wiki with instructions for building > newer versions of X than the one included with oi_151a ( > http://wiki.openindiana.org/oi/Building+XNV_174a+on+oi_151a). I'm a bit > unclear on the contents because it alternately refers to both XNV_174a and > XNV_175a. The latest version I see in the Mercurial repository is 174a, but > the article mentions success building 175a and suggests updating to 175a > for > Sandy Bridge graphics support. Does this mean Sandy Bridge graphics are not > supported by XNV_174a? I'm interested in a laptop that comes with Intel HD > 3000 graphics and want to explore the possibility of getting it to work > using the instructions in this article. > > Thanks, > Ian Johnson > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ce networks and aggregations
Solved ;) Found a coubple of rge compatible cards, just 60? each :) Thanx! -- Da: James Carlson A: Discussion list for OpenIndiana Data: 13 ottobre 2011 15.06.06 CEST Oggetto: Re: [OpenIndiana-discuss] ce networks and aggregations Gabriele Bulfon wrote: noI don't think I will ever call Oracle for support, this is not an option. If I won't find any way to aggregate these two cards, I will more easily throw away these machines and change them into x86+OI :) EBay sounds like a good plan B for an over-constrained problem. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Aggregation performance measurement
Hi, I recently could join an old Sun Sparc machine to an OpenIndiana storage, by adding a couple of ethernets to the Sparc machine running Solaris 10/08. The Sparc machine is now connected to the storage switch, LACP capable. I understand that dladm on Solaris 10 is still different from the OpenIndiana version, so maybe the problem I see comes from here. I created two trunks of two ports each on the switch, connected the Sparc on one trunk, the storage on the other trunk, aggregated cards on both machines through dladm, configured aggr1 on both machines, verified that machines can see each other. All four links are up and quiet on the switch, nothing was moving. So I used "netio" to check network throughput, resulting around 90MB/sec: strange, this is less than 1Gb/sec! Is aggregation workgin? So, I started transfering data from the Sparc to the storage via NFS, and looking at the switch, I could see one machine working on both ports of his trunk, while the other one was almost working on just one port..that is something more than 1Gb/sec!why?? So I tried removing the "sleeping" cable, and measured the same throughput Strangely, I tried removing the "working" cable, and insterted the "sleeping" one, and still everything was working on one port, the "sleeping" one became operational. Added again the second one, and that was become the "sleeping" one Looks like aggregation is not using all the available throughput..what am I missing? is there any incompatibility between Solaris10/08 and OpenIndiana? Thanx for any help. Gabriele. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Mixing zfs raids and mirrors
Hi, I was wondering what (if any) problems I may encounter by mixing different zfs strategies on one pool, with all equal disk sizes. Examples: - pool1: raidz1 a0 a1 a2 mirror a3 a4 - pool2: raidz1 b0 b1 b2 raidz1 b3 b4 b5 mirror b6 b7 - pool3: mirror c0 c1 mirror c2 c3 raidz c4 c5 c6 I'm just trying to balance pools performance and maximum space... Last but not least: - what if pool3 is actually the rpool (where system just occupies few GBytes), where I'll add volumes with quotas to share? Should I keep rpool separate absolutely? (I just don't want to miss many GB on an rpool that will just stay as it is, on the boot disks). Thanx so much, Gabriele. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Aggregation performance measurement
Gabriele Bulfon wrote: > Hi, > I recently could join an old Sun Sparc machine to an OpenIndiana storage, by > adding a couple of > ethernets to the Sparc machine running Solaris 10/08. > The Sparc machine is now connected to the storage switch, LACP capable. > I understand that dladm on Solaris 10 is still different from the OpenIndiana > version, so maybe > the problem I see comes from here. > I created two trunks of two ports each on the switch, connected the Sparc on > one trunk, the storage > on the other trunk, aggregated cards on both machines through dladm, > configured aggr1 on both > machines, verified that machines can see each other. > All four links are up and quiet on the switch, nothing was moving. > So I used "netio" to check network throughput, resulting around 90MB/sec: > strange, this is > less than 1Gb/sec! Is aggregation workgin? There's no way to know based on that. Since performance sounds exceptionally low, I would look for low-level errors first. A fairly common (and unfortunate) cause of low performance like this occurs when a system administrator attempts to "force" Ethernet duplex without fully understanding what "forced" mode means. (When duplex is "forced" on one side of a link, this disables normal autonegotiation, and that causes the other side to drop into the minimum supported configuration; typically half-duplex. If you feel compelled to force Ethernet parameters, you must do it on both sides of the link.) Another common cause is plain old bad cables. Swapping out cables is a good thing to try. Look for errors on the link. Look at kstats. Try running without trunking first to see if you can get decent single-link performance before dealing with the complexity of trunking. There's no reason to reach for a complicated solution if the simple things aren't working right. > So, I started transfering data from the Sparc to the storage via NFS, and > looking at the switch, > I could see one machine working on both ports of his trunk, while the other > one was almost > working on just one port..that is something more than 1Gb/sec!why?? That's not too surprising, depending on how the trunks are configured and what sort of traffic is passing over the links. Standards-compliant Ethernet trunking requires the peers to distribute packets among the links in a way that precludes accidental packet reordering. 802 just doesn't allow reordering. Generally, this means that the peers must hash based on some kind of flow-identifying information. At a minimum, this is usually the MAC addresses. But it can include any other data the peers like, as long as reordering within a flow is precluded. The more information used, and the more individual flows present, the better statistical balance you get. But there are no guarantees in life. Sometimes everything hashes to one link, even if you try hard. Look at the configuration again. How are the trunks set up? What sort of flow identification is used? It is the sender (not recipient) who is responsible for picking the output port used for any given packet, so look at the sending side of the "unbalanced" traffic. Look at the traffic itself. Is there more than one flow in that direction? If no, then seeing it all on one link is perfectly normal and expected. Trunking doesn't just add the two bandwidths together! > So I tried removing the "sleeping" cable, and measured the same throughput > Strangely, I tried removing the "working" cable, and insterted the "sleeping" > one, and still > everything was working on one port, the "sleeping" one became operational. > Added again the second one, and that was become the "sleeping" one > Looks like aggregation is not using all the available throughput..what am > I missing? is there > any incompatibility between Solaris10/08 and OpenIndiana? I don't expect that there should be any. More likely, I expect a misconfiguration somewhere in this set-up. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Aggregation performance measurement
On Mon, Oct 17, 2011 at 4:12 PM, Gabriele Bulfon wrote:
> Hi,
> I recently could join an old Sun Sparc machine to an OpenIndiana storage, by
> adding a couple of
> ethernets to the Sparc machine running Solaris 10/08.
> The Sparc machine is now connected to the storage switch, LACP capable.
> I understand that dladm on Solaris 10 is still different from the OpenIndiana
> version, so maybe
> the problem I see comes from here.
> I created two trunks of two ports each on the switch, connected the Sparc on
> one trunk, the storage
> on the other trunk, aggregated cards on both machines through dladm,
> configured aggr1 on both
> machines,
Ah, but how? What's the actual configuration you used?
In particular, what's the sharing policy ('dladm show-aggr -L')?
My experience with S10 was that I only got both paths in use when
I set the sharing policy to combine L2 and L3.
> All four links are up and quiet on the switch, nothing was moving.
> So I used "netio" to check network throughput, resulting around 90MB/sec:
> strange, this is
> less than 1Gb/sec! Is aggregation workgin?
> So, I started transfering data from the Sparc to the storage via NFS, and
> looking at the switch,
> I could see one machine working on both ports of his trunk, while the other
> one was almost
> working on just one port..that is something more than 1Gb/sec!why??
> So I tried removing the "sleeping" cable, and measured the same throughput
> Strangely, I tried removing the "working" cable, and insterted the "sleeping"
> one, and still
> everything was working on one port, the "sleeping" one became operational.
> Added again the second one, and that was become the "sleeping" one
> Looks like aggregation is not using all the available throughput..what am
> I missing? is there
> any incompatibility between Solaris10/08 and OpenIndiana?
> Thanx for any help.
> Gabriele.
>
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Mixing zfs raids and mirrors
Gabriele Bulfon wrote: > Hi, > I was wondering what (if any) problems I may encounter by mixing different > zfs strategies on one pool, > with all equal disk sizes. > Examples: > - pool1: raidz1 a0 a1 a2 mirror a3 a4 > - pool2: raidz1 b0 b1 b2 raidz1 b3 b4 b5 mirror b6 b7 > - pool3: mirror c0 c1 mirror c2 c3 raidz c4 c5 c6 > I'm just trying to balance pools performance and maximum space... > Last but not least: > - what if pool3 is actually the rpool (where system just occupies few > GBytes), where I'll add > volumes with quotas to share? Should I keep rpool separate absolutely? > (I just don't want to miss many GB on an rpool that will just stay as it is, > on the boot disks). Last I checked, it wasn't possible to boot off of RAID-Z; only mirrors were supported for boot. As for the other part, the man page says: Virtual devices cannot be nested, so a mirror or raidz vir- tual device can only contain files or disks. Mirrors of mir- rors (or other combinations) are not allowed. If you're looking to boost RAID-Z performance, I'd suggest adding more disks. RAID-Z will effectively stripe the data across the available devices, parallelizing the I/O operations. To get better error tolerance, use raidz2 or raidz3. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Aggregation performance measurement
> In particular, what's the sharing policy ('dladm show-aggr -L')?
>
> My experience with S10 was that I only got both paths in use when
> I set the sharing policy to combine L2 and L3.
Yes, that is also my experience. Here is what I currently have for
configuration on the one aggregation I use more than sporadically:
# dladm show-aggr -L
key: 1 (0x0001) policy: L2,L3 address: 0:23:8b:xx:yy:zz (fixed)
LACP mode: active LACP timer: short
deviceactivity timeout aggregatable sync coll dist defaulted expired
bge0 active short yes yes yes yes nono
nge0 active short yes yes yes yes nono
This is the only useable config: active, short timeout, use L2+L3.
OS is S10 U9/x64. But still it is not used symmetrically:
# dladm show-aggr -s
key:1 ipackets rbytes opackets obytes %ipkts %opkts
Total 466841076 446265645314 418989589 87606162787
bge051668621815551300 321053212 560109195 1.176.6
nge0461674214 50094014 97936377 8704605359298.923.4
[BTW this command could use a -h switch for MB/GB display :-)]
I guess if more clients talked to this server, the load would be spread
out more. But I only have max 2-3 clients creating traffic at any given
time.
Regards -- Volker
--
Volker A. Brandt Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] extreme sloth on fresh install bootup
I've just installed oi on a vm (virtualbox) as guest on an older P4 3.06 with 2gb ram an running Debian wheezy as HOST OS. I gave the oi OS only 900mb of ram. On reboot following install I'm seeing what seems to be inordinate sloth in the boot process. As the services are being enumerated its taking most of 1 second for each increase (up to 168) .. which is quite a lot of seconds. Or is this a one time thing and later reboots will be faster? While I've been writing this I see now that things are slowing even more. Where the enumerator is taking more than a second now. 133 to 135 (of 168 services) took about 10 seconds. This can't be normal eh? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] After install for text based iso
I've just installed oi 151 from the text based installer: oi-dev-151a-text-x86.iso To get a minimum basic gui desktop what pkgs would need to be installed? There is such a vast array of X related stuff to look through from the command line, I'm having trouble figuring out what is basic. Some are obvious but I'd like to have a list of whats of needed on tap. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] AMD FX-8150 ("Bulldozer") CPUs
On Oct 16, 2011, at 10:09 PM, Mark Humphreys wrote: > On Sun, Oct 16, 2011 at 6:49 PM, Robar Philip wrote: > >> Notice though that its 8 cores are not a win for builds, whereas the build >> test is one of the few tests where the core i7 2600K really separates itself >> from the rest of the pack—being almost 30% faster than its nearest >> competitor and 50% faster than the rest of the pack. >> >> Does anyone have any idea as to why the core i7 is such a win for builds? >> >> Phil > > Hyper-threading, which was reintroduced with the Core i7 / Nehalem chips, > combined with techniques like branch-execution prediction and higher clock > speeds make the Intel offering more powerful; but, of course, more > expensive. > > http://en.wikipedia.org/wiki/Hyper-threading Ah, I knew that my Core i5 2500S didn’t have hyper-threading, but I didn’t realize that none of Core i5s have it. I guess Intel was smart enough to know that a hyper-threaded i5 would perform so closely to an i7 that it would remove much of the incentive to buy an i7. It amazes me that the CPU market is such that it makes sense for Intel to make 39 different Sandy Bridge desktop CPUs*. And if the myriad of variations in speed, turbo mode, L3 cache, graphics performance (normal and turbo) and power usage were’t enough to numb your mind, then a little digging at CPU World will show you that Intel turns off features like virtualization support for various models—so you can’t have your cake and eat it too. Phil * http://en.wikipedia.org/wiki/Sandy_Bridge#Desktop_processors ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] After install for text based iso
Harry Putnam writes: > I've just installed oi 151 from the text based installer: > oi-dev-151a-text-x86.iso > > To get a minimum basic gui desktop what pkgs would need to be > installed? > > There is such a vast array of X related stuff to look through from the > command line, I'm having trouble figuring out what is basic. Some are > obvious but I'd like to have a list of whats of needed on tap. I might need to say `nevermind'. I finally dug up one lonesome hit on one of those printouts from an irc channel where someone mentioned slim_install. So unless that is not all there is to it... I may be good to go. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] extreme sloth on fresh install bootup
On Tue, Oct 18, 2011 at 03:08, Harry Putnam wrote: > I've just installed oi on a vm (virtualbox) as guest on an older P4 > 3.06 with 2gb ram an running Debian wheezy as HOST OS. > > I gave the oi OS only 900mb of ram. > > On reboot following install I'm seeing what seems to be inordinate sloth > in the boot process. As the services are being enumerated its taking > most of 1 second for each increase (up to 168) .. which is quite a lot > of seconds. > > Or is this a one time thing and later reboots will be faster? > > While I've been writing this I see now that things are slowing even > more. Where the enumerator is taking more than a second now. 133 to > 135 (of 168 services) took about 10 seconds. > > This can't be normal eh? The first boot is slower because all the manifests for the system services are being loaded in for the first time. However, the amount of RAM also has a great impact on the speed OpenIndiana runs at, and I won't suggest to run it with less than 2 GB, if you want to use it for anything. This is in part because ZFS likes to cache as much as it can in RAM, but will not be able to if the RAM is taken up by the rest of the system. -- Venlig hilsen / Kind regards Jeppe Toustrup (aka. Tenzer) ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
