> > Will you be supporting iSCSI in addition to NFS and > CIFS? Initially, we're only targeting the NFS and CIFS protocols, partly because files that back iSCSI LUNs may very well be migrated as part of the migration of the file system. Doesn't cover the other iSCSI cases but one thing at a time.
> > Will there be controls added to throttle the speed of > the replication > process? Will the replication tool natively support > compression and > encryption? Are there synchronous and asynchronous > modes > of operation? All good questions. Yes, we envision a very intuitive means of controlling the resources assigned to each file system migration task -- literally a slider bar on the UI that would indicate "how hard to work". DMM can then use this guide to influence its use of system resources. One could imagine that network bandwidth may be one of the critical factors to manage. The early thinking at this point on compression and encryption (toss in checksumming as well) is that we're going to be placing DMM at the mercy of the protocols. So, if NFSv4 or a certain CIFS protocol dialect offers these services, DMM will certainly take advantage of them. In absense of protocol support, we don't have a good story yet -- could use help there in thinking. Yes, DMM will support both asynchronous background migration controlled by limited policy as well as "on-demand" or perhaps synchronous access to files from processes relating to client activity. Just a quick note on terminology between replication and migration. We're viewing migration as the UNIX 'mv' as opposed to replication being the UNIX 'cp'. One transfers the location of a dataset to another location vs. creating two locations. DMM will be operating in a mode where the source is marked read-only to ensure that only 1 live location of the data exists. Hope that's clear. > > Based on the description above, it sounds like the > client will be stopped > hile their data is migrated from one location to > another. Is this actually > the case? Yes, if the data hadn't already been moved by the asynchronous portion and a process accesses the file (or portion thereof), the process will be blocked while DMM determines the best way to get that process back in action with the requested data. May involve transferring only the data for that request or perhaps the whole file. Key here is to minimize latency. Worth noting that once a file is migrated, DMM is out of the picture from that point on. Mark This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
