It's actually worse than that--it's not just "recent CPUs" without VT
support. Very few of Intel's current low-price processors, including
the Q8xxx quad-core desktop chips, have VT support.
On Wed, Jun 24, 2009 at 12:09 PM, roland wrote:
>>Dennis is correct in that there are significant areas wh
>Dennis is correct in that there are significant areas where 32-bit
>systems will remain the norm for some time to come.
think of that hundreds of thousands of VMWare ESX/Workstation/Player/Server
installations on non VT capable cpu`s - even if the cpu has 64bit capability, a
VM cannot run in 6
On Sat, Jun 20, 2009 at 2:53 AM, Miles Nordin wrote:
>> "fan" == Fajar A Nugraha writes:
>> "et" == Erik Trimble writes:
>
> fan> The N610N that I have (BCM3302, 300MHz, 64MB) isn't even
> fan> powerful enough to saturate either the gigabit wired
>
> I can't find that device. Did you
> "fan" == Fajar A Nugraha writes:
> "et" == Erik Trimble writes:
fan> The N610N that I have (BCM3302, 300MHz, 64MB) isn't even
fan> powerful enough to saturate either the gigabit wired
I can't find that device. Did you misspell it or something? BCM
probably means Broadcom, and
Erik Trimble wrote:
Fajar A. Nugraha wrote:
Are they feasible targets for zfs?
The N610N that I have (BCM3302, 300MHz, 64MB) isn't even powerful
enough to saturate either the gigabit wired or 802.11n wireless. It
only goes about 25Mbps.
Last time I test on EEPC 2G's Celeron, zfs is slow to the
On Fri, Jun 19, 2009 at 11:16 AM, Erik Trimble wrote:
> I can't say as to the entire Atom line of stuff, but I've found the Atoms
> are OK for desktop use, and not anywhere powerful enough for even a basic
> NAS server. The demands of wire-speed Gigabit, ZFS, and
> encryption/compression are hard
Fajar A. Nugraha wrote:
On Thu, Jun 18, 2009 at 4:28 AM, Miles Nordin wrote:
djm> http://opensolaris.org/os/project/osarm/
yeah. many of those ARM systems will be low-power
builtin-crypto-accel builtin-gigabit-MAC based on Orion and similar,
NAS (NSLU2-ish) things begging for ZFS.
On Thu, Jun 18, 2009 at 4:28 AM, Miles Nordin wrote:
> djm> http://opensolaris.org/os/project/osarm/
>
> yeah. many of those ARM systems will be low-power
> builtin-crypto-accel builtin-gigabit-MAC based on Orion and similar,
> NAS (NSLU2-ish) things begging for ZFS.
Are they feasible targets f
> "cd" == Casper Dik writes:
>> yeah. many of those ARM systems will be low-power
>> builtin-crypto-accel builtin-gigabit-MAC based on Orion and
>> similar, NAS (NSLU2-ish) things begging for ZFS.
cd> So what's the boot environment they use?
i think it is called U-Boot:
>yeah. many of those ARM systems will be low-power
>builtin-crypto-accel builtin-gigabit-MAC based on Orion and similar,
>NAS (NSLU2-ish) things begging for ZFS.
So what's the boot environment they use?
>cd> It's true for most of the Intel Atom family (Zxxx and Nxxx but
>cd> not the 23
> "djm" == Darren J Moffat writes:
> "cd" == Casper Dik writes:
djm> http://opensolaris.org/os/project/osarm/
yeah. many of those ARM systems will be low-power
builtin-crypto-accel builtin-gigabit-MAC based on Orion and similar,
NAS (NSLU2-ish) things begging for ZFS.
cd> It's
roland wrote:
Solaris is NOT a super-duper-plays-in-all-possible-spaces OS.
yes, i know - but it`s disappointing that not even 32bit and 64bit x86 hardware
is handled the same.
1TB limit on 32bit, less stable on 32bit.
sorry, but if you are used to linux, solaris is really weird.
issue
>Solaris is NOT a super-duper-plays-in-all-possible-spaces OS.
yes, i know - but it`s disappointing that not even 32bit and 64bit x86 hardware
is handled the same.
1TB limit on 32bit, less stable on 32bit.
sorry, but if you are used to linux, solaris is really weird.
issue here, limitation ther
> > 32 bit Solaris can use at most 2^31 as disk address; a disk block is
> > 512bytes, so in total it can address 2^40 bytes.
> >
> > A SMI label found in Solaris 10 (update 8?) and OpenSolaris has been
> > enhanced
> > and can address 2TB but only on a 64 bit system.
>
> is what the problem is.
thank you, caspar.
to sum up here (seems to have been a lot of confusion in this thread):
the efi vs. smi thing that richard and a few other people have talked
about is not the issue at the heart of this. this:
> 32 bit Solaris can use at most 2^31 as disk address; a disk block is
> 512bytes, so
Erik Trimble wrote:
Dennis is correct in that there are significant areas where 32-bit
systems will remain the norm for some time to come. And choosing a
32-bit system in these areas is completely correct.
That said, I think the issue is that (unlike Linux), Solaris is NOT a
super-duper-plays
>> Not a ZFS bug. IIRC, the story goes something like this: a SMI
>> label only works to 1 TByte, so to use > 1 TByte, you need an
>> EFI label. For older x86 systems -- those which are 32-bit -- you
>> probably have a BIOS which does not handle EFI labels. This
>> will become increasingly irr
casper@sun.com wrote:
> >ie, I can have >1Tb disks as part of a non-bootable data pool, with EFI
> >labels, on a 32-bit machine?
>
> No; the daddr_t is only 32 bits.
This looks like a left over problem problem from former times when UFS was
limited to 1 TB anyway.
Jörg
--
EMail:jo...@sc
> Not a ZFS bug. IIRC, the story goes something like this: a SMI
> label only works to 1 TByte, so to use > 1 TByte, you need an
> EFI label. For older x86 systems -- those which are 32-bit -- you
> probably have a BIOS which does not handle EFI labels. This
> will become increasingly irritatin
casper@sun.com wrote:
It's true for most of the Intel Atom family (Zxxx and Nxxx but not the
230 and 330 as those are 64 bit) Those are new systems.
Casper
___
I've actually just started to build my home raid using the Atom 330
(D945GCLF2):
>> Not a ZFS bug. [SMI vs EFI labels vs BIOS booting]
>
>and so also only a problem for disks that are members of the root pool.
>
>ie, I can have >1Tb disks as part of a non-bootable data pool, with EFI
>labels, on a 32-bit machine?
No; the daddr_t is only 32 bits.
Casper
_
>$ psrinfo -pv
>The physical processor has 1 virtual processor (0)
> x86 (CentaurHauls 6A9 family 6 model 10 step 9 clock 1200 MHz)
>VIA Esther processor 1200MHz
>
>Also, some of the very very small little PC units out there, those things
>called eePC ( or whatever ) are probably 32-bit
>roland wrote:
>> so, we have a 128bit fs, but only support for 1tb on 32bit?
>>
>> i`d call that a bug, isn`t it ? is there a bugid for this? ;)
>>
>
>Not a ZFS bug. IIRC, the story goes something like this: a SMI
>label only works to 1 TByte, so to use > 1 TByte, you need an
>EFI label. Fo
So you better post the nice and clean zfs error message that you got on
your screen, instead of posting about things that you might ignore.
To give the correct information, leads to your correct solution. In your
case possible, the patchlevel, or /format -e/ issue.
Think about it !
milosz schri
Dennis is correct in that there are significant areas where 32-bit
systems will remain the norm for some time to come. And choosing a
32-bit system in these areas is completely correct.
That said, I think the issue is that (unlike Linux), Solaris is NOT a
super-duper-plays-in-all-possible-spac
> Not a ZFS bug. [SMI vs EFI labels vs BIOS booting]
and so also only a problem for disks that are members of the root pool.
ie, I can have >1Tb disks as part of a non-bootable data pool, with EFI labels,
on a 32-bit machine?
--
This message posted from opensolaris.org
___
On Wed, Jun 17, 2009 at 8:32 AM, Neal Pollack wrote:
> Not sure I understand all this concern. 32 bit can use 1.0 TB disks as data
> drives. ZFS can use more than 1 disk. So if you hook up 48 of the 1.0 TB
> disks
> using ZFS on a 32 bit system, where is the problem?
+1.
Even if someone needs
> On Tue, 16 Jun 2009, roland wrote:
>
>> so, we have a 128bit fs, but only support for 1tb on 32bit?
>>
>> i`d call that a bug, isn`t it ? is there a bugid for this? ;)
>
> I'd say the bug in this instance is using a 32-bit platform in 2009! :-)
Rich, a lot of embedded industrial solutions are
roland wrote:
so, we have a 128bit fs, but only support for 1tb on 32bit?
i`d call that a bug, isn`t it ? is there a bugid for this? ;)
Not a ZFS bug. IIRC, the story goes something like this: a SMI
label only works to 1 TByte, so to use > 1 TByte, you need an
EFI label. For older x86 sy
On 06/16/09 03:22 PM, Ray Van Dolson wrote:
On Tue, Jun 16, 2009 at 03:16:09PM -0700, milosz wrote:
yeah i pretty much agree with you on this. the fact that no one has
brought this up before is a pretty good indication of the demand.
there are about 1000 things i'd rather see fixed/improved
On Tue, Jun 16, 2009 at 04:25:58PM -0700, Toby Thain wrote:
>
> On 16-Jun-09, at 6:22 PM, Ray Van Dolson wrote:
>
> > On Tue, Jun 16, 2009 at 03:16:09PM -0700, milosz wrote:
> >> yeah i pretty much agree with you on this. the fact that no one has
> >> brought this up before is a pretty good indi
On 16-Jun-09, at 6:22 PM, Ray Van Dolson wrote:
On Tue, Jun 16, 2009 at 03:16:09PM -0700, milosz wrote:
yeah i pretty much agree with you on this. the fact that no one has
brought this up before is a pretty good indication of the demand.
there are about 1000 things i'd rather see fixed/improv
On Tue, Jun 16, 2009 at 03:16:09PM -0700, milosz wrote:
> yeah i pretty much agree with you on this. the fact that no one has
> brought this up before is a pretty good indication of the demand.
> there are about 1000 things i'd rather see fixed/improved than max
> disk size on a 32bit platform.
I
yeah i pretty much agree with you on this. the fact that no one has
brought this up before is a pretty good indication of the demand.
there are about 1000 things i'd rather see fixed/improved than max
disk size on a 32bit platform.
On Tue, Jun 16, 2009 at 5:55 PM, Neal Pollack wrote:
> On 06/16/0
On Tue, 16 Jun 2009, roland wrote:
> so, we have a 128bit fs, but only support for 1tb on 32bit?
>
> i`d call that a bug, isn`t it ? is there a bugid for this? ;)
I'd say the bug in this instance is using a 32-bit platform in 2009! :-)
--
Rich Teer, SCSA, SCNA, SCSECA
URLs: http://www.rite-
On 06/16/09 02:39 PM, roland wrote:
so, we have a 128bit fs, but only support for 1tb on 32bit?
i`d call that a bug, isn`t it ? is there a bugid for this? ;)
Well, opinion is welcome.
I'd call it an RFE.
With 64 bit versions of the CPU chips so inexpensive these days,
how much money do yo
so, we have a 128bit fs, but only support for 1tb on 32bit?
i`d call that a bug, isn`t it ? is there a bugid for this? ;)
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/m
yeah, i get a nice clean zfs error message about disk size limits when
i try to add the disk.
On Tue, Jun 16, 2009 at 4:26 PM, roland wrote:
>>the only problems i've run into are: slow (duh) and will not
>>take disks that are bigger than 1tb
>
> do you think that 1tb limit is due to 32bit solaris
>the only problems i've run into are: slow (duh) and will not
>take disks that are bigger than 1tb
do you think that 1tb limit is due to 32bit solaris ?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.or
>Ive asked the same question about 32bit. I created a thread and asked.
>
It were something like "does 32bit ZFS fragments RAM?" or something similar.
>As I remember it, 32 bit had some issues. Mostly due to RAM fragmentation or
>something similar. The result was that you had to restart your serve
one of my disaster recovery servers has been running on 32bit hardware
(ancient northwood chip) for about a year. the only problems i've run into
are: slow (duh) and will not take disks that are bigger than 1tb. that is
kind of a bummer and means i'll have to switch to a 64bit base soon.
everyth
I had a 32 bit zfs server up for months with no such issue
Performance is not great but it's no buggier than anything else. War
stories from the initial zfs drops notwithstanding
khb...@gmail.com | keith.bier...@quantum.com
Sent from my iPod
On Jun 15, 2009, at 3:59 PM, Orvar Korvar
wrote
Ive asked the same question about 32bit. I created a thread and asked. It were
something like "does 32bit ZFS fragments RAM?" or something similar. As I
remember it, 32 bit had some issues. Mostly due to RAM fragmentation or
something similar. The result was that you had to restart your server a
so, besides performance there COULD be some stability issues.
thanks for the answers - i think i`ll stay with 32bit, even if there COULD be
issues. (i`m happy to report and help fixing those)
i don`t have free 64bit hardware around for building storage boxes.
--
This message posted from opensol
Daniel Carosone wrote:
This sounds like FUD.
There's a comprehensive test suite, and it apparently passes.
It's not exactly FUD. If you search the list archives, you'll find
messages about multiple bugs in the 32-bit code. I strongly suspect that
these have been fixed in the interim, but it
This sounds like FUD.
There's a comprehensive test suite, and it apparently passes.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
There is a 32-bit and 64-bit version of the file system module
available on x86. Given the quality of the development team, I'd be *very*
surprised if such issues as suggested in your message exist.
Jurgen's comment highlights the major issue - the lack of space to
cache data when in 32-bit mode.
Jürgen Keil wrote:
besides performance aspects, what`s the con`s of
running zfs on 32 bit ?
The default 32 bit kernel can cache a limited amount of data
(< 512MB) - unless you lower the "kernelbase" parameter.
In the end the small cache size on 32 bit explains the inferior
performance comp
> besides performance aspects, what`s the con`s of
> running zfs on 32 bit ?
The default 32 bit kernel can cache a limited amount of data
(< 512MB) - unless you lower the "kernelbase" parameter.
In the end the small cache size on 32 bit explains the inferior
performance compared to the 64 bit kern
Hello,
the ZFS best practices guide at
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide tells:
>* Run ZFS on a system that runs a 64-bit kernel
besides performance aspects, what`s the con`s of running zfs on 32 bit ?
--
This message posted from opensolaris.org
_
> How does eeprom(1M) work on the Xeon that the OP said he has?
its faked via /boot/solaris/bootenv.rc
built into /platform/i86pc/$ISADIR/boot_archive
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/
On Jun 29, 2007, at 23:34, Rob Logan wrote:
eeprom kernelbase=0x8000
or for only 1G userland:
eeprom kernelbase=0x5000
How does eeprom(1M) work on the Xeon that the OP said he has?
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
ht
> issues does ZFS have with running in only 32-bit mode?
with less then 2G ram, no worry... with more then 3G ram
and you don't need mem in userspace, give it to the kernel
in virtual memory for zfs cache by moving the kernelbase...
eeprom kernelbase=0x8000
or for only 1G userland:
eeprom ker
I'm looking at replacing my current old version of Linux with
OpenSolaris. The catch is that I'm running my home fileserver on a dual
P3 Xeon system, which is 32-bit. Given that I'm not really too worried
about performance, and that I don't expect to be putting more than 6
drives and about 2T
54 matches
Mail list logo