Re: Snapper snapshot comparison algorithm - send/receive questions
Arvin, On Mon, Dec 3, 2012 at 1:35 PM, Arvin Schnell aschn...@suse.de wrote: On Sat, Dec 01, 2012 at 01:24:20PM +0530, nafisa mandliwala wrote: I needed help with understanding the snapshot comparison algorithm that snapper uses and its shortcomings. From reading the code, what I understood is that it does a block by block compare. I'm not very sure if that's the best way to go about it. Also, since the send receive code is still in development stages, is there a scope to add more functionality to it? Mainly snapper does a directory traversal and a block-by-block comparison of files which is indeed a inefficient comparison algorithm. I already had a look at using the new send/receive ioctl to improve the comparison and have a few question: 1. snapper only needs to know that a file has changed but the send stream also contains the new content which might has to be read from disk. Mark Fasheh has made a patch for a flag for the send ioctl to not include the content (don't know if he posted it here since I was kicked of the list twice). With no write commands in the stream how can I detect a file content change? Currently there seems to be a truncate after the write but is that guaranteed? Btw: There are many apparently useless truncates, e.g. after a chmod. What are these good for? Currently, any S_ISREG() file (i.e., not a directory, symlink etc.) that is considered as changed, will have a truncate command to ensure correct file size at the receive side. There may perhaps be room for optimization here, though. 2. Is it possible to add a ioctl for send that takes open file-descriptors for parent_root and clone_sources? Otherwise it's insecure to use from snapper (which has root privileges and sometimes operates in directories users can modify). Such a ioctl would also reduce the number of btrfs related functions needed. 3. Overall lots of functions are needed to use the send/receive. Are there any plans to create a btrfs-library that contains the required functions e.g. btrfs_read_and_process_send_stream, subvol_uuid_search and tree_search? Regards, Arvin Alex. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Snapper snapshot comparison algorithm - send/receive questions
On Sat, Dec 01, 2012 at 01:24:20PM +0530, nafisa mandliwala wrote: I needed help with understanding the snapshot comparison algorithm that snapper uses and its shortcomings. From reading the code, what I understood is that it does a block by block compare. I'm not very sure if that's the best way to go about it. Also, since the send receive code is still in development stages, is there a scope to add more functionality to it? Mainly snapper does a directory traversal and a block-by-block comparison of files which is indeed a inefficient comparison algorithm. I already had a look at using the new send/receive ioctl to improve the comparison and have a few question: 1. snapper only needs to know that a file has changed but the send stream also contains the new content which might has to be read from disk. Mark Fasheh has made a patch for a flag for the send ioctl to not include the content (don't know if he posted it here since I was kicked of the list twice). With no write commands in the stream how can I detect a file content change? Currently there seems to be a truncate after the write but is that guaranteed? Btw: There are many apparently useless truncates, e.g. after a chmod. What are these good for? 2. Is it possible to add a ioctl for send that takes open file-descriptors for parent_root and clone_sources? Otherwise it's insecure to use from snapper (which has root privileges and sometimes operates in directories users can modify). Such a ioctl would also reduce the number of btrfs related functions needed. 3. Overall lots of functions are needed to use the send/receive. Are there any plans to create a btrfs-library that contains the required functions e.g. btrfs_read_and_process_send_stream, subvol_uuid_search and tree_search? Regards, Arvin -- Arvin Schnell, aschn...@suse.de Senior Software Engineer, Research Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
