Alasdair,
Success with 148 dev_il and the Thinkpad Z61 as well! It's nice to be
able to install OpenIndiana after failed attempts with 148 and 148b.
The Thinkpad is a bit starved for memory (1G) for
OpenSolaris/OpenIndiana, but 148 dev_il boots up and shuts down in
roughly half the time tha
On Apr 23, 2011, at 12:29 PM, Gary Driggs wrote:
>> Unless you buy the fishworks based storage products, which I believe
>> includes the dedup feature and is sold for production environments. I just
>> don't remember if the dedup feature is labelled experimental or similar.
>
> The unified sto
Not at this time. Most of the traffic is writes and I'm probably going to
go iSCSI for now - I don't really have the time or inclination to chase this
anymore at this point, although I do appreciate the helpful suggestions
various people have made.
-Original Message-
From: Gordon Ross [m
[...]
>> Redid the CIFS bench just now. 38MB/sec read, 77MB/sec write. So ftp is
>> almost twice as fast.
>
> OK, so next I'd grab a network capture of just a couple seconds during
> the "middle" part of both of these transfer tests, and compare the delays
> seen between requests and responses.
>
On 04/23/11 06:01 AM, Edward Ned Harvey wrote:
>> From: Alan Coopersmith [mailto:alan.coopersm...@oracle.com]
>>
>> While I'm fairly sure Oracle disagrees with Mr. Harvey's claim that it's
>> not considered production worthy,
>
> Here's what I meant when I said that:
> The current production rele
On Apr 23, 2011, at 8:21 AM, Gregory Youngblood wrote:
> Unless you buy the fishworks based storage products, which I believe includes
> the dedup feature and is sold for production environments. I just don't
> remember if the dedup feature is labelled experimental or similar.
The unified stor
Unless you buy the fishworks based storage products, which I believe includes
the dedup feature and is sold for production environments. I just don't
remember if the dedup feature is labelled experimental or similar.
Sent from my Droid Incredible.
Edward Ned Harvey wrote:
>> From: Alan Coope
On 23.04.2011, at 16:10, Edward Ned Harvey wrote:
>> From: Toomas Soome [mailto:toomas.so...@mls.ee]
>>
>> well, do a bit math. if ima correct, with 320B DTT the 1.75GB of ram can
> fit
>> 5.8M entries, 1TB of data, assuming 128k recordsize would produce 8M
>> entries thats with default meta
Hello,
I have compiled ntfs-3g under OpenIndiana 148 and it works just fine.
Also, I have made some patches and I have send them to the developers for
review. If anyone wants to test the package, please send me an e-mail
off-list.
Regards,
A.S.
--
Apostolos Syropoulos
Xan
> From: Tomas Bodzar [mailto:tomas.bod...@gmail.com]
>
> Isn't it too much?
"Too much ram" is an oxymoron.
Always add more ram. And then double the ram. Or else don't complain about
performance. ;-)
___
OpenIndiana-discuss mailing list
OpenIndi
On Sat, Apr 23, 2011 at 3:06 PM, Edward Ned Harvey
wrote:
>> From: Roy Sigurd Karlsbakk [mailto:r...@karlsbakk.net]
>>
>> That's theory, in practice, even with sufficient RAM/L2ARC and some amount
>> of SLOG, dedup slows down writes to a minimum. My test was done with 8TB
>> net storage, 8GB RAM,
> From: Toomas Soome [mailto:toomas.so...@mls.ee]
>
> well, do a bit math. if ima correct, with 320B DTT the 1.75GB of ram can
fit
> 5.8M entries, 1TB of data, assuming 128k recordsize would produce 8M
> entries thats with default metadata limit. unless i did my
calculations
> wrong, that wil
> From: Roy Sigurd Karlsbakk [mailto:r...@karlsbakk.net]
>
> That's theory, in practice, even with sufficient RAM/L2ARC and some amount
> of SLOG, dedup slows down writes to a minimum. My test was done with 8TB
> net storage, 8GB RAM, and two 80GB x25-M SSDs devided into 2x4GB SLOG
> (mirrored) an
> From: Alan Coopersmith [mailto:alan.coopersm...@oracle.com]
>
> While I'm fairly sure Oracle disagrees with Mr. Harvey's claim that it's
> not considered production worthy,
Here's what I meant when I said that:
The current production release is still Solaris 10, which does not include
dedup ye
On 04/22/11 05:55 AM, Dan Swartzendruber wrote:
> Hmmm, looks like it might be realtek lossage. Crystaldiskmark just finished
> the read phase. Getting about 56MB/sec, which isn't tremendous, but it
> beats the snot out of the 33 or so the RT was generating. I then re-ran the
> iSCSI crystaldisk
15 matches
Mail list logo
