Depends on how you define DR - we have shared storage HA in each datacenter
(NetApp cluster), and replication between them in case we lose a datacenter
(all clients on the MAN hit the same cluster unless we do a DR failover). The
latter is what I'm calling DR.
It's what I call HA. DR is wha
Shared storage is evil (in this context). Corrupt the storage, and you have
no DR.
Now I am confused. We're talking about storage which can be used for
failover, aren't we? In which case we are talking about HA not DR.
That goes for all block-based replication products as well. This is
no
No, I haven't tried a S7000, but I've tried other kinds of network
storage and from a design perspective, for my applications, it doesn't
even make a single bit of sense. I'm talking about high-volume real-time
video streaming, where you stream 500-1000 (x 8Mbit/s) live streams from
a machine ov
This is a silly argument, but...
Haven't seen any underdog proven solid enough for me to deploy in
enterprise yet.
I haven't seen any "over"dog proven solid enough for me to be able to rely
on either. Certainly not Solaris. Don't get me wrong, I like(d) Solaris.
But every so often you'd fi
This is slightly off topic, so I apologise in advance.
I'm investigating the option of offering private "cloud storage". I've
found many things which offer features that I want, but nothing that seems
to glue them all together into a useful whole. Thus I would like to pick
your collective b
What you probably want is a motherboard which has a small area of main
memory protected by battery, and a ramdisk driver which knows how to use it.
Then you'd get the 1,000,000 IOPS. No idea if anyone makes such a thing.
You are correct that ZFS gets an enormous benefit from even tiny amounts i
Unless you have two or three or nine of these things and you spread data
around. For the $ 1M that they claim a petabyte from Sun costs, they're able
to make nine of their pods.
It is the claim of the cost from Sun that I am sceptical about. I admit
that it will be more expensive, and I kno
> A cleanly written filesystem provides clean and abstract interfaces to do
> anything you like with the filesystem, it's content and metadata. In such an
> environment, there is no need for a utility that knows the disk layout (like
> ufsdump does).
I'd like to take a backup of a live filesystem
> For home use I am making very successful use of zfs incremental send
> and receive. A script decides which filesystems to backup (based
> on a user property retrieved by zfs get) and snapshots the filesystem;
> it then looks for the last snapshot that the pool I'm backing
> up and the pool I'm b
> I think I have heard something called dirty time logging being implemented
> in ZFS.
Thanks for the pointer. Certainly interesting, but according to the
talks/emails I've found a month or so ago ZFS "will offer" this, so I am
guessing it isn't there yet, and certainly not in a released versi
> Remember to also deploy IPsec to protect the iSCSI traffic. You want at
> least IPsec with AH to get integrity protection on the wire and for cross
> site you likely what ESP+Auth as well.
How will this help given dark fibre between the sites? I'm not doing this
over a public internet!
>
Someone suggested an idea, which the more I think about the less insane it
sounds. I thought I would ask the assembled masses to see if anyone had
tried anything like this, and how successful they had been.
I'll start with the simplest variant of the solution, but there are
potentially subtle
> Hi list,
>
> I'd like to be able to store zfs filesystems on a tape drive that is
> attached to another Solaris U4 x86 server. The idea is to use "zfs send"
> together with tar in order to get the list of the filesystems' snapshots
> stored on a tape and be able to perform a restore operation
>
> I can not export lofs on NFS. Just gives invalid path,
Tell that to our mirror server.
-bash-3.00$ /sbin/mount -p | grep linux
/data/linux - /linux lofs - no ro
/data/linux - /export/ftp/pub/linux lofs - no ro
-bash-3.00$ grep linux /etc/dfs/sharetab
/linux - nfs ro Linux dire
> Wow, that a neat idea, and crazy at the same time. But the mknod's minor
> value can be 0-262143 so it probably would be doable with some loss of
> memory and efficiency. But maybe not :) (I would need one lofi dev per
> filesystem right?)
>
> Definitely worth remembering if I need to do somethi
> (I don't suppose there is some hack to let me cross file-systems?)
I believe that if you lofs mount the filesystems under, say, /export you
can share that directory and have all the subdirectories appear.
We certainly do that for a single directory at a time.
> On the NFS client side, this wo
Okay .. that is disk to disk or system to system. I can only assume
that you have large pipes of bandwidth ( 10 GE ) to move data around
with.
System to system. No, we have 100Mbit to the backup system. The systems
being backed up are small though, they are primarily people's desktops.
The
Can we discuss this with a few objectives ? Like define "backup" and
then describe mechanisms that may achieve one? Or a really big
question that I guess I have to ask, do we even care anymore?
Personally I think you would benefit from some slightly different terms.
I would differentiate b
I take it you already have solved the problem.
Yes, my problems went away once my device supported the extended SCSI
instruction set.
Julian
--
Julian King
Computer Officer, University of Cambridge, Unix Support
___
zfs-discuss mailing list
zfs-di
On Mon, 17 Jul 2006, Cindy Swearingen wrote:
Hi Julian,
Can you send me the documentation pointer that says 2 TB isn't supported
on the Solaris 10 6/06 release?
As per my original post:
http://docs.sun.com/app/docs/doc/817-5093/6mkisoq1k?a=view#disksconcepts-17
This doesn't say which version
Well if in fact sd/ssd with EFI labels still have limit to 2TB than
create SMI label with one slice representing whole disk and then put
zfs on that slice. Eventually manually turn on write cache then.
Well, in fact it turned out that the firmware on the device needed
upgrading to support the a
Well if in fact sd/ssd with EFI labels still have limit to 2TB than
create SMI label with one slice representing whole disk and then put
zfs on that slice. Eventually manually turn on write cache then.
How do you suggest that I create a slice representing the whole disk?
format (with or without
Possibly not the right list, but the only appropriate one I knew about.
I have a Solaris box (just reinstalled to Sol 10 606) with a 3.19TB device
hanging off it, attatched by fibre.
Solaris refuses to see this device except as a 1.19 TB device.
Documentation that I have found
(http://docs.
23 matches
Mail list logo
