eric kustarz wrote:
>
> On Mar 6, 2008, at 7:58 AM, Brian D. Horn wrote:
>
>> Take a look at CR 6634371. It's worse than you probably thought.
>
> The only place i see ZFS mentioned in that bug report is regarding
> z_mapcnt. Its being atomically inc/dec in zfs_addmap()/zfs_delmap() -
> so thos
On Mar 6, 2008, at 7:58 AM, Brian D. Horn wrote:
> Take a look at CR 6634371. It's worse than you probably thought.
The only place i see ZFS mentioned in that bug report is regarding
z_mapcnt. Its being atomically inc/dec in zfs_addmap()/zfs_delmap()
- so those are ok.
In zfs_frlock(), te
On Fri, Mar 7, 2008 at 11:43 AM, Brian D. Horn <[EMAIL PROTECTED]> wrote:
> If you look at the contents of the CR it does say that. However there
> are something like 200 instances and of those perhaps one or two
> dozen are NOT statistics. A few examples from around the kernel
> were pointed
If you look at the contents of the CR it does say that. However there
are something like 200 instances and of those perhaps one or two
dozen are NOT statistics. A few examples from around the kernel
were pointed out. (interrupt handling, NIC driver, ZFS, ...)
This message posted from opensol
It isn't a simple as getting an old stale value. You can get a totally
incorrect
value. Example:
Let us assume a monotonically increased 64-bit values which at the start
of this discussion is: 0x (32-bits 0, 32-bits 1).
The 32-bit kernel goes to read the 64-bit value and does s
On Thu, Mar 06, 2008 at 10:29:46AM -0500, Rob Logan wrote:
> > ZFS is not 32-bit safe.
>
> while this is kinda true, if the systems has 2G or less of ram
> it shouldn't be an issue other than poor performance for lack of
> ARC.
So what happens if you have a 32-bit machine with 4GB RAM like I do?
On Thu, Mar 06, 2008 at 02:07:09PM +0100, Mattias Pantzare wrote:
>
> I don't know how to change the ARC sise, but use this to increase
> kernel addres space:
>
> eeprom kernelbase=0x5000
Ah ha, that's what I was thinking about.
> Your user address space will shrink when you do that.
Yes,
>Brian D. Horn wrote:
>> Take a look at CR 6634371. It's worse than you probably thought.
>>
>
>Actually, almost all of the problems noted in that bug are statistics.
But not exactly all and some are used for othe rpurposes.
And some of the other values will never exceed 32 bit in 32 bit sys
Paul -
Don't substitute redundancy for backup...
if your data is important to you, for the love of steak, make sure you
have a backup that would not be destroyed by, say, a lightening strike,
fire or stray 747.
For what it's worth, I'm also using ZFS on 32 bit and am yet to
experience any sor
Brian D. Horn wrote:
> Take a look at CR 6634371. It's worse than you probably thought.
>
Actually, almost all of the problems noted in that bug are statistics.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/bart
Take a look at CR 6634371. It's worse than you probably thought.
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Mar 6, 2008 at 10:22 AM, Brian D. Horn <[EMAIL PROTECTED]> wrote:
> ZFS is not 32-bit safe. There are a number of places in the ZFS code where
> it is assumed that a 64-bit data object is being read atomically (or set
> atomically). It simply isn't true and can lead to weird and bugs.
>ZFS is not 32-bit safe. There are a number of places in the ZFS code where
>it is assumed that a 64-bit data object is being read atomically (or set
>atomically). It simply isn't true and can lead to weird and bugs.
Where do you get that information?
(First I've heard of it and I have a hard
> ZFS is not 32-bit safe.
while this is kinda true, if the systems has 2G or less of ram
it shouldn't be an issue other than poor performance for lack of
ARC.
Rob
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://
Brian D. Horn wrote:
> ZFS is not 32-bit safe. There are a number of places in the ZFS code where
> it is assumed that a 64-bit data object is being read atomically (or set
> atomically). It simply isn't true and can lead to weird and bugs.
Bug numbers please.
--
Darren J Moffat
__
ZFS is not 32-bit safe. There are a number of places in the ZFS code where
it is assumed that a 64-bit data object is being read atomically (or set
atomically). It simply isn't true and can lead to weird and bugs.
This message posted from opensolaris.org
__
2008/3/6, Brian Hechinger <[EMAIL PROTECTED]>:
> On Thu, Mar 06, 2008 at 11:39:25AM +0100, [EMAIL PROTECTED] wrote:
> >
> > I think it's specfically problematic on 32 bit systems with large amounts
> > of RAM. Then you run out of virtual address space in the kernel quickly;
> > a small amount
On Thu, Mar 06, 2008 at 11:39:25AM +0100, [EMAIL PROTECTED] wrote:
>
> I think it's specfically problematic on 32 bit systems with large amounts
> of RAM. Then you run out of virtual address space in the kernel quickly;
> a small amount of RAM (I have one with 512MB) works fine.
I have a 32-bit
>Ben wrote:
>> Hi,
>>
>> I know that is not recommended by Sun
>> to use ZFS on 32 bits machines but,
>> what are really the consequences of doing this ?
>
>Depends on what kind of performance you need.
>
>> I have an old Bipro Xeon server (6 GB ram , 6 disks),
>> and I would like to do a raidz
Ben wrote:
> Hi,
>
> I know that is not recommended by Sun
> to use ZFS on 32 bits machines but,
> what are really the consequences of doing this ?
Depends on what kind of performance you need.
> I have an old Bipro Xeon server (6 GB ram , 6 disks),
> and I would like to do a raidz with 4 disks
Hi,
I know that is not recommended by Sun
to use ZFS on 32 bits machines but,
what are really the consequences of doing this ?
I have an old Bipro Xeon server (6 GB ram , 6 disks),
and I would like to do a raidz with 4 disks with Solaris 10 update 4.
Thanks,
Ben
___
21 matches
Mail list logo
