Obviously, I should stop answering, as all I deal with and all that I will
deal with is GA Solaris. OpenSolaris might as well not exist as far as I'm
concerned. With that in mind, I'll just keep reading and appreciating all of
the good zfs info that comes along.

Peace out.

On Tue, Jul 29, 2008 at 5:54 PM, eric kustarz <[EMAIL PROTECTED]> wrote:

>
> On Jul 29, 2008, at 2:24 PM, Chris Cosby wrote:
>
>
>>
>> On Tue, Jul 29, 2008 at 5:13 PM, Stefano Pini <[EMAIL PROTECTED]>
>> wrote:
>> Hi guys,
>> we are  proposing  a customer  a couple of X4500 (24 Tb) used as NAS (i.e.
>> NFS server).
>> Both server will contain the same files and should be accessed by
>> different clients at the same time (i.e. they should be both active)
>> So we need to guarantee that both x4500 contain the same files:
>> We could simply copy the contents on both x4500 , which is an option
>> because the "new files" are in a limited number and rate , but we would
>> really like to use ZFS send & receive commands:
>> If they are truly limited, something like an rsync or similar. There was a
>> script being thrown around a while back that was touted as the Best Backup
>> Script That Doesn't Do Backups, but I can't find it. In essence, it just
>> created a list of what changed since the last backup and allowed you to use
>> tar/cpio/cp - whatever to do the backup.
>>
>
> I think zfs send/recv would be a great way to go here - see below.
>
>
>>
>>
>>
>> AFAIK the commands works fine but  generally speaking are there any known
>> limitations ?
>> And, in detail , it is not clear  if the receiving ZFS file system could
>> be used regularly while it is in "receiving mode":
>> in poor words is it possible to read and export in nfs,   files from a
>>  ZFS file system while it is receiving update from  another  ZFS send ?
>> First, the zfs send works only on a snapshot. -i sends incremental
>> snapshots, so you would think that would work. From the zfs man page, you'll
>> see that during a receive, the destination file system is unmounted and
>> cannot be accessed during the receive.
>>
>>          If an incremental stream is received, then the  destina-
>>         tion file system must already exist, and its most recent
>>         snapshot must match the incremental stream's source. The
>>         destination  file  system and all of its child file sys-
>>         tems are unmounted and cannot  be  accessed  during  the
>>         receive operation.
>>
>
> Actually we don't unmount the file systems anymore for incremental
> send/recv, see:
> 6425096 want online 'zfs recv' (read only and read/write)
>
> Available since November 2007 in OpenSolaris/Nevada.  Coming to a s10u6
> near you.
>
> eric
>



-- 
chris -at- microcozm -dot- net
=== Si Hoc Legere Scis Nimium Eruditionis Habes
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to