Re: [OpenIndiana-discuss] branding for illumos/openindiana

[Benediktus Anindito]

On Sat, Jun 25, 2011 at 6:45 AM, Christopher Chan
 wrote:
> On Saturday, June 25, 2011 01:21 AM, Mark Humphreys wrote:
>>
>> On Fri, Jun 24, 2011 at 9:44 AM, Kent Watsen  wrote:
>>
>>>
>>> "Open Indiana" is a goofy name, even considering its history, but the
>>> acronym is OK.
>>>
>>>
>> How about just shortening it to "OpenIndy"?  :)
>>
>
> +1
>
> :-D
>
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
OpenIndy looks fancy :))

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Question about drive LEDs

[Mark]

On 24/06/2011 11:09 p.m., Fred Liu wrote:
> Mark,
> 
> Can you post the content of your blog in this list?
> 
> Many thanks.
> 
>>>
>>> look here.
>>>
>>> http://stored-on-zfs.blogspot.com
>>>

In brief, I cloned a bootable SATA disk from the VMware (now
discontinued) Sun Unified Storage simulator, and then created the
graphics and definitions to match a Supermicro 4U chassis and system board.
Everything worked exactly as a real one would, including disk locator
led's, disk present/absent graphics etc. and was able to be updated with
new firmware.

Since it was origionally designed as an generic appliance kit and there
was mention of it being available as Software, this was relatively easy
to do.
It is definitely Solaris based, but has some quite different drivers
etc. than OpenSolaris.

IPMI is required to make it work.

There are quite a few xml files to configure, along with graphics.
It is also very easy to crash the management svc with invalid definitions.


sample definition:








  

  








  



  
 
  

   
   
   
   

 
 
 
 


  

  







Mark.


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Brainstorming for OpenIndiana server

[Chris Mosetick]

I have OpenIndiana running on several machines. On one of them, I'm using
OpenIndiana b148 as my main operating system, storage server and virtual
machine host all in one physical machine. It does have dedicated ZIL and
L2ARC devices to increase performance. I'm using VirtualBox 4.0.x as my
virtual machine hypervisor, and *I'm not* using virtualbox default .vdi for
virtual machines, instead I'm using ZFS zvols for my VM disks in conjunction
with VirtualBox's built-in "raw disk access". (which in this case is not
technically raw) It only takes a couple command lines to get it going and
the performance has been great for me so far. I have Linux and Windows host
running this way, even my firewall, running m0n0wall is running in there.

I highly recommend using OpenIndiana as your VM host in conjunction with raw
disk access. Run your Linux machines as VM's. You will need a lot more ram
regardless of what you want to do.

Here is an example:

# virtualbox 4.0.x has already been installed.
# "lift" is the name of a dedicated storage zpool
# zimbra is the name of the virtual machine in VirtualBox, but will also be
used as the name for zvol storage purposes.

zfs create -s -V 100G -o volblocksize=128K lift/vboxhosts/zimbra
zfs set compression=gzip-6 lift/vboxhosts/zimbra
<>
chown admin:sysadmin /dev/zvol/rdsk/lift/vboxhosts/zimbra
VBoxManage internalcommands createrawvmdk -filename
/lift/vboxhosts/zimbra/zimbra.vmdk -rawdisk
/dev/zvol/rdsk/lift/vboxhosts/zimbra
VBoxManage storageattach zimbra --storagectl "SAS Controller" --port 0
--device 0 --type hdd --medium /lift/vboxhosts/zimbra.vmdk
<>



On Wed, Jun 22, 2011 at 1:50 PM, Alex Smith (K4RNT)
wrote:

> I'm thinking about setting up a RAID-Z training server, with Linux as
> a base. Yes, I know it's weird, but hear me out.
>
> I have an AMD Opteron server that I'm repurposing from my old
> workstation. I may be putting a hot-swap cage in here, and using the
> onboard nforce (ahci) controller with a Linux host, running
> OpenIndiana in a VirtualBox instance. Could it be possible to pass the
> raw devices to the VM via a SATA controller, and then run the drives
> in a RAID-Z configuration? Unless the root pool can be set up on
> install as RAID-Z, I can use a virtual disk
>
> Host will have an AMD Opteron 1352 with 4GB DDR2 RAM.
>
> --
> " ' With the first link, the chain is forged. The first speech
> censured, the first thought forbidden, the first freedom denied,
> chains us all irrevocably.' Those words were uttered by Judge Aaron
> Satie as wisdom and warning... The first time any man's freedom is
> trodden on we’re all damaged." - Jean-Luc Picard, quoting Judge Aaron
> Satie, Star Trek: TNG episode "The Drumhead"
> - Alex Smith (K4RNT)
> - Sterling, Virginia USA
>
> ___
> 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] write speeds faster with no ZIL and L2ARC

[Chris Mosetick]

Hi,

*Problem:*
write speeds are faster when no L2ARC or ZIL is configured.

*Our current setup:*
We are currently running OpenIndiana b148 (upgraded from b134.) Supermicro
X8DTH-i/6/iF/6F, single Xeon E5504, 24GB ram. A single, main storage pool is
running pool version 28, populated with 12 WD RE 7200rpm SATA disks in a
RAIDZ2. This pool has two 32GB Intel X25-E SSD's for ZIL and L2ARC connected
directly to SATA ports on the motherboard. The entire system has been in
operation for about one year with minimal issues. About a week ago we
started seeing slow write performance so troubleshooting began.

*What we have done so far / what we know:*
We removed the ZIL and L2ARC SSD's from the server, zpool remove tank c6t1d0
c6t0d0
and connected them to a windows machine and ran Intel SSD
Toolon
them. (a windows only application)

Using Intel SSD Toolbox 2.0.2.000, we see the following values;

09 Power-On Hours Count:
  ZIL:Raw: 6783
  L2ARC: Raw: 8562

E9 Media Wearout Indicator:
  ZIL: Raw: 0  Normalized: 99  Threshold: 0
  L2ARC:  Raw: 0  Normalized: 99  Threshold: 0

E1 Host Writes
  ZIL: Raw: 47 TB  Normalized: 200  Threshold: 0
  L2ARC:  Raw: 67 TB  Normalized: 199  Threshold: 0

Looking at this, we can only conclude that either;
 1) Intel X25-E drives have no "wear" even after ~50-60 TB of writes
 2) The wearout indicator is broken and unreliable.

Here are some write tests we have performed using rsync to transfer a 3.5GB
ISO file from my workstation over Gigabit Ethernet to a file system in this
server. All tests go to the same file system unless otherwise noted, and
after each test the already transfered bits were removed from the server.

TRANSFER AMOUNT  TIME TAKEN  NOTES/CONDITIONS
1GB6:00min
tank/shares/sw which has (compression=gzip-6) X25-E ZIL and L2ARC are
present
1GB50sec
rpool/home/chris (two sata disks in mirror, no compression)
1GB3:30
tank pool without L2ARC
1GB1:30
tank pool no L2ARC and no ZIL
500MB4:30
tank pool, brand new ZIL, Corsair F40GB2 (40GB)
500MB3:50
tank pool, new ZIL and new L2ARC, both Corsair F40GB2
800MB6:00
tank pool, new L2ARC and new ZIL have now had ~3 hours to "warm up",
l2arcstat went from 47MB to 22GB

So our problem is that even with brand new SSD's, that have MUCH higher
maximum write speeds then are "old" SSD's, transfers happen to the storage
pool quicker *without* configured log and cache devices, then when they are
being used. FWIW, looking at iostat -exn while running one of the rsync
tests above, the time things are taking seem to match up on the kw/s column.

Can anyone provide insight to this slow write speed situation when ZIL and
L2ARC is present?
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] branding for illumos/openindiana

[Christopher Chan]

On Saturday, June 25, 2011 01:21 AM, Mark Humphreys wrote:

On Fri, Jun 24, 2011 at 9:44 AM, Kent Watsen  wrote:



"Open Indiana" is a goofy name, even considering its history, but the
acronym is OK.



How about just shortening it to "OpenIndy"?  :)



+1

:-D

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Richard L. Hamilton]

On Jun 24, 2011, at 4:17 PM, Dmitry Kozhinov wrote:

> > So I guess it would be fair to say that the best OS is the one that
> > support both at the same time
> 
> Yes, and that's OSol and OI do.

Processes running under 32-bit Solaris can only be 32-bit.
Processes running under 64-bit Solaris can be either.

However, drivers, etc must match the kernel.  And for all
practical purposes, debugging a process (or the kernel)
is a whole lot easier when done by a process with the same
bitness as what it's debugging.  For instance, it may not
be feasible for a 32-bit process to control a 64-bit process
(although the reverse may be possible, if more difficult than
if they were the same).

So the loss of a 32-bit kernel option limits mainly the
hardware you can run on (CPU, but maybe also old drivers that
were never ported to 64-bit).

Other OS's may have somewhat different rules. OS X for instance
can run 64-bit processes on a 32-bit kernel given 64-bit capable
hardware.  I expect that very few OS's would go to the trouble of
supporting 32-bit drivers on a 64-bit OS, for example; not perhaps
100% impossible depending on the driver-to-OS interface, but
certainly extra complexity where it's most dangerous.



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] tuntap 64bit driver

[russell]

Hi,

A few years ago I built a 64bit tuntap driver for Solaris 10 x86 to use 
with VirtualBox and made it available in October 2007. I switched isp 
but the website remains, if you want to try the binary it is still 
available here


http://www.facts4u.dsl.pipex.com/





___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Dmitry Kozhinov]

> So I guess it would be fair to say that the best OS is the one that
> support both at the same time

Yes, and that's OSol and OI do.

On 24.06.2011 22:17, Michael Stapleton wrote:

So I guess it would be fair to say that the best OS is the one that
support both at the same time, and leaves the option to the developer
for each individual application.

My understanding is that Solaris is more like 4G per process/kernel,
rather than 4GB total.
Multiple 32 bit processes could use more than 4GB total; just not
individually.

Mike


On Fri, 2011-06-24 at 15:58 +, Steve Gonczi wrote:


For Intel CPUs, 32 bit code is certainly more compact , and in some cases
arguably faster than 64 bit code. (say, comparing the same code on the same 
machine
compiled 32 and 64 bit)

But, newer cpu silicon tends to make performance improvements
in many ways (e.g locating more supporting circuity on the cpu's silicon, 
increasing L1 /L2
cache sizes, etc)

Newer CPUs also tend to be more energy efficient.
Intel made great strides towards energy efficiency.
E.g.: idling the cpu when not in use ( deep C states etc.
of gating off any circuitry that is not in use, modulating the cpu clock rate
( SpeedStep).

So performance and energy efficiency is more dependent on
which generation of cpu core design we have, rather than on
just the the bitness .


The primary advantage of "64 bit" per se ( ie running a given cpu in 64 bit 
mode)
is the increased addressable memory space.
The current hardware limit set by the manufacturers is at 48 address bits
(256 terabytes theoretical limit) Actual OS support cuts this in half, or less.
Motherboard limitations further curtail this, but 48G motherboards are now
commonplace.

On 32 bit Intel (Amd) you are typically limited to 4G, which is split between 
kernel and userland
depending on the OS and configuration. (E.g.: 1G kernel and 3G userland)

Steve

- "Michael Stapleton"  wrote:


While we are talking about 32 | 64 bit processes;
Which one is better?
Faster?
More efficient?

Mike






___
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



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] branding for illumos/openindiana

[Doug Bora]

On 6/24/2011 10:45 AM, Dan Swartzendruber wrote:

Kent Watsen wrote:


"Open Indiana" is a goofy name, even considering its history, but the
acronym is OK.

Similar to how Kentucky Fried Chicken is now KFC, can we consider
emphasizing "oi"?

As long as the reaction people get when installing and using it is not
"OY!"


How about Oui!

("Yes!" in French)

I do agree though that the OI acronym works fairly well.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Alan Coopersmith]

On 06/24/11 08:58 AM, Steve Gonczi wrote:
> For Intel CPUs, 32 bit code is certainly more compact , and in some cases 
> arguably faster than 64 bit code. (say, comparing the same code on the same 
> machine 
> compiled 32 and 64 bit) 

But 64-bit code has access to more registers, which can make a measurable
difference for some code.   SPARC is much more like you say, since the
registers and ISA's are basically the same between the two modes, leaving
it down to things like accessing a greater range of memory vs. doubling
the memory used by every pointer address & long int.

-- 
-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] branding for illumos/openindiana

[Mark Humphreys]

On Fri, Jun 24, 2011 at 9:44 AM, Kent Watsen  wrote:

>
> "Open Indiana" is a goofy name, even considering its history, but the
> acronym is OK.
>
>
How about just shortening it to "OpenIndy"?  :)

-- 
.\\ark
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Dan Swartzendruber]

Steve Gonczi wrote:

I really can not make a case for 32 bit except for a legacy binary where you do 
Not have a choice

Do we need a 32 bit kernel ?
Probably not. Do we need the ability
To run a 32 bit binary?I think so
  
Well, can't speak to opensolaris, but for 64-bit linux and windows, you 
can run 32-bit executables just fine, so that argument is not 
compelling, IMO...


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Steve Gonczi]

I really can not make a case for 32 bit except for a legacy binary where you do 
Not have a choice

Do we need a 32 bit kernel ?
Probably not. Do we need the ability
To run a 32 bit binary?I think so
-:::-sG-:::-

On Jun 24, 2011, at 12:17, Michael Stapleton 
 wrote:

> So I guess it would be fair to say that the best OS is the one that
> support both at the same time, and leaves the option to the developer
> for each individual application.
> 
> My understanding is that Solaris is more like 4G per process/kernel,
> rather than 4GB total.
> Multiple 32 bit processes could use more than 4GB total; just not
> individually.
> 
> Mike
> 
> 
> On Fri, 2011-06-24 at 15:58 +, Steve Gonczi wrote:
> 
>> For Intel CPUs, 32 bit code is certainly more compact , and in some cases 
>> arguably faster than 64 bit code. (say, comparing the same code on the same 
>> machine 
>> compiled 32 and 64 bit) 
>> 
>> But, newer cpu silicon tends to make performance improvements 
>> in many ways (e.g locating more supporting circuity on the cpu's silicon, 
>> increasing L1 /L2 
>> cache sizes, etc) 
>> 
>> Newer CPUs also tend to be more energy efficient. 
>> Intel made great strides towards energy efficiency. 
>> E.g.: idling the cpu when not in use ( deep C states etc. 
>> of gating off any circuitry that is not in use, modulating the cpu clock 
>> rate 
>> ( SpeedStep). 
>> 
>> So performance and energy efficiency is more dependent on 
>> which generation of cpu core design we have, rather than on 
>> just the the bitness . 
>> 
>> 
>> The primary advantage of "64 bit" per se ( ie running a given cpu in 64 bit 
>> mode) 
>> is the increased addressable memory space. 
>> The current hardware limit set by the manufacturers is at 48 address bits 
>> (256 terabytes theoretical limit) Actual OS support cuts this in half, or 
>> less. 
>> Motherboard limitations further curtail this, but 48G motherboards are now 
>> commonplace. 
>> 
>> On 32 bit Intel (Amd) you are typically limited to 4G, which is split 
>> between kernel and userland 
>> depending on the OS and configuration. (E.g.: 1G kernel and 3G userland) 
>> 
>> Steve 
>> 
>> - "Michael Stapleton"  wrote: 
>> 
>> 
>> While we are talking about 32 | 64 bit processes; 
>> Which one is better? 
>> Faster? 
>> More efficient? 
>> 
>> Mike 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___ 
>> 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

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Michael Stapleton]

So I guess it would be fair to say that the best OS is the one that
support both at the same time, and leaves the option to the developer
for each individual application.

My understanding is that Solaris is more like 4G per process/kernel,
rather than 4GB total.
Multiple 32 bit processes could use more than 4GB total; just not
individually.

Mike


On Fri, 2011-06-24 at 15:58 +, Steve Gonczi wrote:

> For Intel CPUs, 32 bit code is certainly more compact , and in some cases 
> arguably faster than 64 bit code. (say, comparing the same code on the same 
> machine 
> compiled 32 and 64 bit) 
> 
> But, newer cpu silicon tends to make performance improvements 
> in many ways (e.g locating more supporting circuity on the cpu's silicon, 
> increasing L1 /L2 
> cache sizes, etc) 
> 
> Newer CPUs also tend to be more energy efficient. 
> Intel made great strides towards energy efficiency. 
> E.g.: idling the cpu when not in use ( deep C states etc. 
> of gating off any circuitry that is not in use, modulating the cpu clock rate 
> ( SpeedStep). 
> 
> So performance and energy efficiency is more dependent on 
> which generation of cpu core design we have, rather than on 
> just the the bitness . 
> 
> 
> The primary advantage of "64 bit" per se ( ie running a given cpu in 64 bit 
> mode) 
> is the increased addressable memory space. 
> The current hardware limit set by the manufacturers is at 48 address bits 
> (256 terabytes theoretical limit) Actual OS support cuts this in half, or 
> less. 
> Motherboard limitations further curtail this, but 48G motherboards are now 
> commonplace. 
> 
> On 32 bit Intel (Amd) you are typically limited to 4G, which is split between 
> kernel and userland 
> depending on the OS and configuration. (E.g.: 1G kernel and 3G userland) 
> 
> Steve 
> 
> - "Michael Stapleton"  wrote: 
> 
> 
> While we are talking about 32 | 64 bit processes; 
> Which one is better? 
> Faster? 
> More efficient? 
> 
> Mike 
> 
> 
> 
> 
> 
> 
> ___ 
> 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] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Dmitry Kozhinov]

The main difference is (in)ability to use large amount of RAM.

32-bit systems use 32-bit pointers, and maximum value of unsigned 32-bit 
integer is 2^32,
or 4Gb. In practice many 32-bit OSes are able to address only 2Gb of RAM.

64-bit pointers can address much more RAM (no hardware has reached 2^64 RAM 
limit yet).

Nowadays even laptops may have 4 or 8 Gb of RAM, not to mention servers,
which should have much more. So, 32-bit OS is a past day OS, for legacy 
hardware only.

Unfortunately not everyone can afford a new hardware.
My web server has 1 GB RAM and 32-bit processor :(
Happily running OSol b134 :)

Regards,
Dmitry.


 While we are talking about 32 | 64 bit processes;
 Which one is better?
 Faster?
 More efficient?



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Steve Gonczi]

For Intel CPUs, 32 bit code is certainly more compact , and in some cases 
arguably faster than 64 bit code. (say, comparing the same code on the same 
machine 
compiled 32 and 64 bit) 

But, newer cpu silicon tends to make performance improvements 
in many ways (e.g locating more supporting circuity on the cpu's silicon, 
increasing L1 /L2 
cache sizes, etc) 

Newer CPUs also tend to be more energy efficient. 
Intel made great strides towards energy efficiency. 
E.g.: idling the cpu when not in use ( deep C states etc. 
of gating off any circuitry that is not in use, modulating the cpu clock rate 
( SpeedStep). 

So performance and energy efficiency is more dependent on 
which generation of cpu core design we have, rather than on 
just the the bitness . 


The primary advantage of "64 bit" per se ( ie running a given cpu in 64 bit 
mode) 
is the increased addressable memory space. 
The current hardware limit set by the manufacturers is at 48 address bits 
(256 terabytes theoretical limit) Actual OS support cuts this in half, or less. 
Motherboard limitations further curtail this, but 48G motherboards are now 
commonplace. 

On 32 bit Intel (Amd) you are typically limited to 4G, which is split between 
kernel and userland 
depending on the OS and configuration. (E.g.: 1G kernel and 3G userland) 

Steve 

- "Michael Stapleton"  wrote: 


While we are talking about 32 | 64 bit processes; 
Which one is better? 
Faster? 
More efficient? 

Mike 






___ 
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] branding for illumos/openindiana

[Dmitry Kozhinov]

> As long as the reaction people get when installing and using it is 
not "OY!"


Yes :)))

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] branding for illumos/openindiana

[Dan Swartzendruber]

Kent Watsen wrote:


"Open Indiana" is a goofy name, even considering its history, but the 
acronym is OK.


Similar to how Kentucky Fried Chicken is now KFC, can we consider 
emphasizing "oi"?

As long as the reaction people get when installing and using it is not "OY!"



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] branding for illumos/openindiana

[Kent Watsen]

"Open Indiana" is a goofy name, even considering its history, but the 
acronym is OK.


Similar to how Kentucky Fried Chicken is now KFC, can we consider 
emphasizing "oi"?


Graphics for "oi" would be easy to make look sharp for a nice "out of 
the box" experience



On 6/21/11 5:00 AM, peter jones wrote:

Oi is easally transferable across cultures..a new beginning is about
aligning to todays market..clearly there is an issue about building brand
associations..it was surely the intent to look at marketing after the distro
had undertaken a certain amount of devlopment?

On 21 Jun 2011 00:53, "Blake"  wrote:

Does anyone besides me feel that we need a more unified naming/branding
approach for the community-driven descendants of OpenSolaris? I feel that
the there is no obvious connection (for those new to the platform) between
Illumos/OpenIndiana, which I think is counterproductive given that
OpenIndiana is sort of the 'Fedora Core' of Illumos.

Some possible names:

Illumos Live

Illumos Core

Illumos [version_number] - [adjective] [animal]





(kidding about the last one)


I think OpenIndiana is great, I just don't think that the name 'Indiana'
means anything to anyone and isn't very memorable.


Blake
___
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] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Dustin Marquess]

The answer really is "it depends".

On x86-64, the big advantage to 64-bit performance-wise is the
additional CPU registers that it enables.  The downside is the
additional memory usage due to bigger pointer sizes.  From what I
understand, this increased size can have negative effects on CPU cache
hit rates.

-Dustin

On Fri, Jun 24, 2011 at 7:02 AM, Michael Stapleton
 wrote:
> While we are talking about 32 | 64 bit processes;
> Which one is better?
> Faster?
> More efficient?
>
> Mike
>
>
> On Thu, 2011-06-23 at 13:59 +0100, Deano wrote:
>
>> Windows made the shift last server release (2008r2 is x64 only).
>>
>> So it's only the OSS server families which support 32bit, likely because
>> both BSD and Linux support lots of platforms outside of x86.
>>
>> Deano
>>
>> -Original Message-
>> From: Gary Driggs [mailto:gdri...@gmail.com]
>> Sent: 23 June 2011 02:10
>> To: Discussion list for OpenIndiana
>> Subject: Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for
>> solaris 11 will OI do same?
>>
>> FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move
>> for modern operating systems since there are always going to be alternatives
>> for those still using i386 architecture. How long has Solaris/SPARC been
>> 64-bit? At least ten years if not more...
>>
>> -Gary
>> ___
>> 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
>

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Gary Driggs]

On Jun 23, 2011, Ben Taylor wrote:

> Personally, I wouldn't have signed up for a Kw based pricing scheme which you 
> apparently did)

I didn't as it's one of many data centers that our company built and maintains. 
I just prefer not to be an ass about resources.

-Gary
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for solaris 11 will OI do same?

[Michael Stapleton]

While we are talking about 32 | 64 bit processes; 
Which one is better?
Faster?
More efficient?

Mike


On Thu, 2011-06-23 at 13:59 +0100, Deano wrote:

> Windows made the shift last server release (2008r2 is x64 only).
> 
> So it's only the OSS server families which support 32bit, likely because
> both BSD and Linux support lots of platforms outside of x86.
> 
> Deano
> 
> -Original Message-
> From: Gary Driggs [mailto:gdri...@gmail.com] 
> Sent: 23 June 2011 02:10
> To: Discussion list for OpenIndiana
> Subject: Re: [OpenIndiana-discuss] oracle removes 32bit x86 cpu support for
> solaris 11 will OI do same?
> 
> FWIW, Mac OS X Lion will only support x64 as well. IMHO, this is a good move
> for modern operating systems since there are always going to be alternatives
> for those still using i386 architecture. How long has Solaris/SPARC been
> 64-bit? At least ten years if not more...
> 
> -Gary
> ___
> 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] Question about drive LEDs

[Fred Liu]

Mark,

Can you post the content of your blog in this list?

Many thanks.

>>
>> look here.
>>
>> http://stored-on-zfs.blogspot.com
>>
>>

Fred

> -Original Message-
> From: Mark [mailto:mark0...@gmail.com]
> Sent: 星期五, 六月 24, 2011 16:24
> To: openindiana-discuss@openindiana.org
> Subject: Re: [OpenIndiana-discuss] Question about drive LEDs
> 
> Blinking led's is a "nice to have", but if your server supports ipmi
> and
> ses, the fault management report has already located the disk.
> 
> So I need to replace the disk in ses-enclosure=1/bay=6/disk=0
> 
> 
> Apr 15 2010 22:25:27 abbbe612-1131-6add-f5c9-8537ecb46dc7 DISK-8000-0X
>100%  fault.io.disk.predictive-failure
>  Problem in:
> hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis-
> id=50030480005a337f:serial=6
> XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses-
> enclosure=1/bay=6/disk=0
> Affects:
> dev:///:devid=id1,sd@n5000c50021f4916f//pci@0,0/pci8086,4023@3/pci15d9,
> a680@0/sd@24,
> 0
> FRU:
> hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis-
> id=50030480005a337f:serial=6
> XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses-
> enclosure=1/bay=6/disk=0
>Location: 006
> 
> Mark.
> 
> 
> ___
> 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] Question about drive LEDs

[Mark]

Blinking led's is a "nice to have", but if your server supports ipmi and 
ses, the fault management report has already located the disk.


So I need to replace the disk in ses-enclosure=1/bay=6/disk=0


Apr 15 2010 22:25:27 abbbe612-1131-6add-f5c9-8537ecb46dc7 DISK-8000-0X
  100%  fault.io.disk.predictive-failure
Problem in: 
hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis-id=50030480005a337f:serial=6

XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses-enclosure=1/bay=6/disk=0
   Affects: 
dev:///:devid=id1,sd@n5000c50021f4916f//pci@0,0/pci8086,4023@3/pci15d9,a680@0/sd@24,

0
   FRU: 
hc://:product-id=LSILOGIC-SASX36-A.1:server-id=:chassis-id=50030480005a337f:serial=6

XW15V2S:part=ST32000542AS-ST32000542AS:revision=CC34/ses-enclosure=1/bay=6/disk=0
  Location: 006

Mark.


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] SeaMonkey

[Andrey N. Oktyabrski]

Where I can get the latest (2.1 or 2.2-beta) version package for the 
OpenIndiana? I use 2.0b1 at the moment. It eats 3-4 times less memory 
than the Firefox+Thunderbird.


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss