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: 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 ? Clearly until the new updates are received and applied the old copy would be used TIA Stefano Sun Microsystems Spa Viale Fulvio testi 327 20162 Milano ITALY me *STEFANO PINI* Senior Technical Specialist at Sun Microsystems Italy <http://www.sun.com/italy> contact | stefano.pini at sun.com <mailto:stefano.pini at sun.com> | +39 02 64152150 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Parte allegato al messaggio URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080729/d9f51f38/attachment.ksh>
On Tue, Jul 29, 2008 at 5:13 PM, Stefano Pini <Stefano.Pini at sun.com> 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.> > > 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.> > Clearly until the new updates are received and applied the old copy would > be used > > TIA > Stefano > > > > Sun Microsystems Spa > Viale Fulvio testi 327 > 20162 Milano ITALY > me *STEFANO PINI* > Senior Technical Specialist at Sun Microsystems Italy < > http://www.sun.com/italy> > contact | stefano.pini at sun.com <mailto:stefano.pini at sun.com> | +39 02 > 64152150 > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >-- chris -at- microcozm -dot- net === Si Hoc Legere Scis Nimium Eruditionis Habes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080729/9acf5a17/attachment.html>
Stefano Pini 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)What exactly are they trying to do? AVS can be used to keep two systems in sync, but for a simple design, there should be two NFS file systems, one active for each X4500. There has recently been some discussions on ha-clusters-discuss at opensolaris.org about using AVS to keep the unshared storage in sync. -- richard> 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: > > 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 ? > > Clearly until the new updates are received and applied the old copy > would be used > > TIA > Stefano > > > > Sun Microsystems Spa > Viale Fulvio testi 327 > 20162 Milano ITALY > me *STEFANO PINI* > Senior Technical Specialist at Sun Microsystems Italy > <http://www.sun.com/italy> > contact | stefano.pini at sun.com <mailto:stefano.pini at sun.com> | +39 02 > 64152150 > > > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Jul 29, 2008, at 2:24 PM, Chris Cosby wrote:> > > On Tue, Jul 29, 2008 at 5:13 PM, Stefano Pini <Stefano.Pini at sun.com> > 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
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 <eric.kustarz at sun.com> wrote:> > On Jul 29, 2008, at 2:24 PM, Chris Cosby wrote: > > >> >> On Tue, Jul 29, 2008 at 5:13 PM, Stefano Pini <Stefano.Pini at sun.com> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080729/5b4823d8/attachment.html>
"Chris Cosby" <ccosby+zfs at gmail.com> wrote:> 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.star can do real "incremental" backups using a built-in support for changed files that works the same way as ufsdump does. As a result, star also allows to do incremental restores from these archives which is something other star implementations do not offer in a working way. There is also the pax implementaion from David Korn and Glenn Fowler that does "differential" backups, but I did not yet test this. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
eric kustarz <eric.kustarz at sun.com> wrote:> > 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.It depends: if you like to be able to restore single files, zfs send/recv would not be apropriate. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>It depends: if you like to be able to restore single files, zfs send/recvwould>not be apropriate.Why not? With zfs you can easily view any file/dir from a snapshot (via the .zfs dir). You can also copy that instance of the file into your running fs with cp. justin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3361 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080730/d25c1896/attachment.bin>
Just checking, are you planning to have the receiving ZFS system read only? I''m not sure how ZFS receive works on a system if changes have been made, but I would expect they would be overwritten. This message posted from opensolaris.org