Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> Hi, > > what level of asynchrony do you need? And (out of curiosity) why? > > Cheers, > Felix I'll tell you what I'm trying to do, and maybe that will answer both questions. I'm trying to roll my own disk-based backup solution. Basically, I'll have a Solaris-based system using ZFS to serve volumes out to the systems that I want to back up over iSCSI. This way I can use the ZFS snapshot management capabilities to snapshot the volumes at various points in time, and use the clone capability to represent that volume somewhere in the event that I need a restore done. Also, because ZFS supports remote send/receive out of the box, it gives me a way to send those backups off-site very easily for DR purposes. On the servers I'm trying to back up, I need some form of asynchronous replication. These systems will connect over iSCSI to the ZFS system in order to replicate the volumes. The reason for the asynchronous requirements is because I need to make sure that the replication of the data to the secondary (iSCSI ZFS) disk does not block I/O for the primary volume - I don't want the fact that I'm replicating the data to interfere with performance of the volume. A second concern is that I need to make sure that all I/O operations are actually being done to the primary storage on each of those systems and not to the secondary iSCSI volume, again, mostly for performance reasons. Finally, I want to be able to shut down the ZFS backup system and the iSCSI links without worrying about the system going into any kind of degraded state - it needs to be able to pick the synchronization right back up when it comes back up. The built-in Linux RAID1 driver offers the ability to mark a volume in a RAID1 set as "write mostly", which takes care of most of the concern for having I/O operations occur on the primary device, but does not necessarily insure that write operations will not be blocked by Linux waiting on them to occur on both volumes. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.