Les Mikesell wrote: > Joe Krahn wrote: >> >> As for problems with mapping inodes, I don't see how that is any worse >> than filename lists. In fact, contents are more likely to change with a >> filename reference than by an inode reference. > > At least if you link by name, even if the contents are replaced you'll > end up linked to something that is probably somehow related to what you > expected. If you make a table of inode numbers, then something removes > some files and replaces them even with files of the same names and > contents there would not be much reason to expect the numbers in your > table to still reference the right files. > >> The remote system could >> create temporary files for outstanding links (maybe named by the remote >> inode), to hold an inode reference even if the other files got deleted. > > I'd expect the contents to come along with the first reference. But, > suppose your source filesystem is live and changing, and someone starts > two or more instances of rsync copying to the same destination at once > and they scramble each other's views of the inode numbers - or any other > similar activity happens on the destination side. If that sort of thing > never happened, we wouldn't need to be doing all these backups... > But, if the contents are "replaced", they will get a new inode, and the original data is still under the original inode. That just means that the receiver has to create a temporary file link. As long as those are protected from other users/processes, you are safe. If you link by filename, you end up linking to the modified content on the receiving end, which means having to re-check for changes just before doing the actual link.
If you create an extra hardlink for each inode data reference, and protect it from being deleted, the inode-referenced data can't change. Then at the actual file/link transfer, if the senders file still references the same sender inode, you can do a hardlink at the receiver end to an inode that has to contain the first transfer's content, even if someone on the remote system has deleted the originally transferred file. The only disadvantage is that you have to create a lot of temporary hardlinks, and ensure that at least those are protected from being deleted. But, if they do get deleted, you will know it, and can fall back to less efficient methods. Joe ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
