On 7/22/08 11:48 AM, "Erik Trimble" <[EMAIL PROTECTED]> wrote:
> I'm still not convinced that dedup is really worth it for anything but
> very limited, constrained usage. Disk is just so cheap, that you
> _really_ have to have an enormous amount of dup before the performance
> penalties of dedup a
Oh, I agree. Much of the duplication described is clearly the result of
"bad design" in many of our systems. After all, most of an OS can be served
off the network (diskless systems etc.). But much of the dupe I'm talking
about is less about not using the most efficient system administration
tri
Good points. I see the archival process as a good candidate for adding
dedup because it is essentially doing what a stage/release archiving system
already does - "faking" the existence of data via metadata. Those blocks
aren't actually there, but they're still "accessible" because they're
*somewh
A really smart nexus for dedup is right when archiving takes place. For
systems like EMC Centera, dedup is basically a byproduct of checksumming.
Two files with similar metadata that have the same hash? They're identical.
Charles
On 7/7/08 4:25 PM, "Neil Perrin" <[EMAIL PROTECTED]> wrote:
> M
On 6/27/08 8:55 AM, "Mark J Musante" <[EMAIL PROTECTED]> wrote:
> On Fri, 27 Jun 2008, wan_jm wrote:
>
>> the procedure is follows:
>> 1. mkdir /tank
>> 2. touch /tank/a
>> 3. zpool create tank c0d0p3
>> this command give the following error message:
>> cannot mount '/tank': directory is not empt
On 6/25/08 2:50 PM, "Tim" <[EMAIL PROTECTED]> wrote:
> The issue is cost. It's still cheaper for someone to buy two quad-port
> gig-e cards and trunk all the interfaces than it is for them to buy a single
> 10Gb card.
At the moment, this is quite true. Costs per port are going down (even
10Gig)
On 6/25/08 12:57 PM, "Tim" <[EMAIL PROTECTED]> wrote:
> Uhhh... 64bit/133mhz is 17Gbit/sec. I *HIGHLY* doubt that bus will be a
> limit. Without some serious offloading, you aren't pushing that amount of
> bandwidth out the card. Most systems I've seen top out around 6bit/sec with
> current dri
On 6/23/08 7:45 PM, "Richard Elling" <[EMAIL PROTECTED]> wrote:
> I think the ability to have different policies for file systems
> is pure goodness -- though you pay for it on the backup/
> restore side.
And another reason why Automated Data Migration is the way to go. "Backup"
and "replication
On 6/23/08 11:59 AM, "Tim" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 23, 2008 at 11:18 AM, Edward <[EMAIL PROTECTED]> wrote:
>
>> But the sad thing is Windows XP / Vista is still 32Bit. It doesn't
>> recognize more then 3.x GB of Ram. 64Bit version is still premature and
>> hardly OEM are adopt
On 6/23/08 6:24 AM, "Mertol Ozyoney" <[EMAIL PROTECTED]> wrote:
> No, ZFS loves memory and unlike most other FS's around it can make good use
> of memory. But ZFS will free memory if it recognizes that other apps require
> memory or you can limit the cache ARC will be using.
This is an important
On 6/23/08 6:22 AM, "Mertol Ozyoney" <[EMAIL PROTECTED]> wrote:
> A few days a ago a customer tested a Sunfire X4500 connected to a network
> with 4 x 1 Gbit ethernets. X4500 have modest CPU power and do not use any
> Raid card. The unit easly performaed 400 MB/sec on write from LAN tests
> which
I think the resource emphasis on storage is quite appropriate. The DATA are
the valuable things, not the servers or applications. Appropriately,
servers reached commodity status before storage. But storage hardware will
go that way, and the focus will be on data (storage) management, where it
ope that all storage technologies take a holistic
view of the storage management picture. While ZFS goes a long way to
eliminating distinctions between volume and filesystem management, it is
still a niche player. As much hype as ZFS snapshots get, that's barely
tiptoeing into the man
to comprehend and use than the legacy commands related to storage
> devices. It would be nice if the zfs commands will continue to
> simplify what is now quite obtuse.
>
> Bob
> ==
> Bob Friesenhahn
> [EMAIL PROTECTED], http://www
de.
I had heard it was, and I have to concur. Leopard is the first OS X
automounter that actually works as expected. There was zero fiddling with
our Solaris 10U5 NFS server (a Thumper).
Charles
-
Charles Soto[EMAIL PROTECTED]
Director, Information Technology
The Solaris SAN Configuration and Multipathing Guide proved very helpful for me:
http://docs.sun.com/app/docs/doc/820-1931/
I, too was surprised to see MPIO enabled by default on x86 (we're using Dell/EMC
CX3-40 with our X4500 & X6250 systems).
Charles
Quoting Krutibas Biswal <[EMAIL PROTECTED]
- Sales Manager
>
> Sun Microsystems, TR
> Istanbul TR
> Phone +902123352200
> Mobile +905339310752
> Fax +90212335
> Email <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
>
>
>
>
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.
17 matches
Mail list logo
