On Friday 15 December 2006 19:20, Bryan Henderson wrote: > >The idea behind the cloneset is that most of the blocks (or files) > >do not change in either source or target. This being the case its only > necessary > >to update the changed elements. This means updates are incremental. Once > >the system has figured out what it needs to update its usable and if you > access > >an element that should be updated you will see the correctly updated > version - even > >though backgound resyncing is still in progress. > > I still can't tell what you're describing. With RAID1 as well, only > changed elements ever get updated. I have two identical filesystems, > members of a RAIF set. I change one file. One file in each member > filesystem gets updated, and I again have two identical filesystems. A cloneset is only syncronized at the point in time that you tell it to resync. The source and target fs are useable independently. When you resync the target is reset to be indentical to the source at the point in time of the sync. Its also immediatly useable - the sync and access to the source and target are coordinated so users of the target see the correct data, even if the sync is still running in background. This allows things likes: set oracle in backup mode resync cloneset (this takes about 2 mins for a 2TB cloneset) set oracle out of backup mode (resyncing is still happening in background but accessing the cloneset gives a consistant image) backup oracle using cloneset files or start an instance of oracle using cloneset files (handly for a ro copy or if the main instance needs certian types of service) The overhead of the resync is minimized since it only updates the delta. When dealing with 2TB of data this is an important feature, reducing IO. You can only ask for a resync if the bg process from a previous resync is finished. > How would a cloneset work differently, and how would it be better? > > >This type of logic is great for backups. > > Can you give an example of using it for backup? > > -- > Bryan Henderson IBM Almaden Research Center > San Jose CA Filesystems > > > > - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
