> I must admit though, that the new ACL/ACE model in
> 147 is really nice and slick.
Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just braindead.
chmod resulting in ACLs being discarded is a bizarre design decision.
--
This message posted from opensolaris.org
_
On 09/25/10 02:54 AM, Erik Trimble wrote:
Honestly, I've said it before, and I'll say it (yet) again: unless
you have very stringent power requirement (or some other unusual
requirement, like very, very low noise), used (or even new-in-box,
previous generation excess inventory) OEM stuff is
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Brad Stone
>
> For de-duplication to perform well you need to be able to fit the de-
> dup table in memory. Is a good rule-of-thumb for needed RAM Size=(pool
> capacity/avg block size)*270 byt
Hi all
Has anyone done any testing with dedup with OI? On opensolaris there is a nifty
"feature" that allows the system to hang for hours or days if attempting to
delete a dataset on a deduped pool. This is said to be fixed, but I haven't
seen that myself, so I'm just wondering...
I'll get a 1
> > For de-duplication to perform well you need to be able to fit the
> > de-
> > dup table in memory. Is a good rule-of-thumb for needed RAM
> > Size=(pool
> > capacity/avg block size)*270 bytes? Or perhaps it's
> > Size/expected_dedup_ratio?
>
> For now, the rule of thumb is 3G ram for every 1TB
AFAIK that part of dedup code is not changed in b147.
On Sat, Sep 25, 2010 at 6:54 PM, Roy Sigurd Karlsbakk
wrote:
> Hi all
>
> Has anyone done any testing with dedup with OI? On opensolaris there is a
> nifty "feature" that allows the system to hang for hours or days if
> attempting to delete
When I do the calculations, assuming 300bytes per block to be conservative,
with 128K blocks, I get 2.34G of cache (RAM, L2ARC) per Terabyte of deduped
data. But block size is dynamic, so you will need more than this.
Scott
--
This message posted from opensolaris.org
___
On Sat, Sep 25, 2010 at 10:19 AM, Piotr Jasiukajtis wrote:
> AFAIK that part of dedup code is not changed in b147.
I think I remember seeing that there was a change made in 142 that
helps, though I'm not sure to what extent.
-B
--
Brandon High : bh...@freaks.com
___
On 9/25/2010 1:57 AM, Ian Collins wrote:
On 09/25/10 02:54 AM, Erik Trimble wrote:
Honestly, I've said it before, and I'll say it (yet) again: unless
you have very stringent power requirement (or some other unusual
requirement, like very, very low noise), used (or even new-in-box,
previou
On Thu, Sep 23, 2010 at 1:08 PM, Dick Hoogendijk wrote:
> And about what SUN systems are you thinking for 'home use' ?
> The likeliness of memory failures might be much higher than becoming a
> millionair, but in the years past I have never had one. And my home sytems
> are rather cheap. Mind yo
> On Sat, Sep 25, 2010 at 10:19 AM, Piotr Jasiukajtis wrote:
>> AFAIK that part of dedup code is not changed in b147.
> I think I remember seeing that there was a change made in 142 that
> helps, though I'm not sure to what extent.
> -B
OI seemed to behave much better than 134 in low disk space
On 09/26/10 07:25 AM, Erik Trimble wrote:
On 9/25/2010 1:57 AM, Ian Collins wrote:
On 09/25/10 02:54 AM, Erik Trimble wrote:
Honestly, I've said it before, and I'll say it (yet) again: unless
you have very stringent power requirement (or some other unusual
requirement, like very, very low
hi all
I'm using a custom snaopshot scheme which snapshots every hour, day, week and
month, rotating 24h, 7d, 4w and so on. What would be the best way to zfs
send/receive these things? I'm a little confused about how this works for delta
udpates...
Vennlige hilsener / Best regards
roy
--
> Erik Trimble sez:
> Honestly, I've said it before, and I'll say it (yet) again: unless you
> have very stringent power requirement (or some other unusual
> requirement, like very, very low noise), used (or even new-in-box,
> previous generation excess inventory) OEM stuff is far superior to
> From: opensolaris-discuss-boun...@opensolaris.org [mailto:opensolaris-
> discuss-boun...@opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk
>
> I'm using a custom snaopshot scheme which snapshots every hour, day,
> week and month, rotating 24h, 7d, 4w and so on. What would be the best
> way to z
> From: Roy Sigurd Karlsbakk [mailto:r...@karlsbakk.net]
>
> > For now, the rule of thumb is 3G ram for every 1TB of unique data,
> > including
> > snapshots and vdev's.
>
> 3 gigs? Last I checked it was a little more than 1GB, perhaps 2 if you
> have small files.
http://opensolaris.org/jive/thr
On Sep 25, 2010, at 7:42 PM, "Edward Ned Harvey" wrote:
>> From: opensolaris-discuss-boun...@opensolaris.org [mailto:opensolaris-
>> discuss-boun...@opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk
>>
>> I'm using a custom snaopshot scheme which snapshots every hour, day,
>> week and month, ro
On Sep 25, 2010, at 9:54 AM, Roy Sigurd Karlsbakk wrote:
> Hi all
>
> Has anyone done any testing with dedup with OI? On opensolaris there is a
> nifty "feature" that allows the system to hang for hours or days if
> attempting to delete a dataset on a deduped pool. This is said to be fixed,
>
Thank you very much to Casper for his help. I now have a rpool with 2 x 2TB
HDD's and it's all good :
# zpool list rpool
NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT
rpool 1.82T 640G 1.19T34% 1.09x ONLINE -
It gets quite unhappy if you don't use detach (offline isn't so u
19 matches
Mail list logo
