Carlos E. R. wrote:
El 2014-07-23 a las 21:47 -0700, Linda Walsh escribió:
On might ask why rsync is so slow -- copying 800G from 1 partition to another via xfsdump/restore takes a bit under 2 hours, or about 170MB/s, but with rsync, on the same partition with rsync transfering less than 1/1000th as much (700MB), it took ~70-80 minutes... or about 163kB/s. That's because xfsdump/restore takes shortcuts that rsync can not do. The former doesn't really do a file by file copy. Instead it works with the filesystem metadata directly. It does not need to: find file name, find location of files (sectors), do the actual file read; repeat for every file and directory.
Do you have a reference for this? Because having looked at earlier versions of xfsdump/restore, there IS no metadata section it can dump that is separate from each file.
In XFS the metadata for a file is stored with EACH file. If you are lucky, and it is short enough, it may fit in the inode (the inodes are spread out all over the disk to put inodes next to or near their data to minimize seek times). If it cannot fit in the inode, it's in a separate data fork -- that must be read separately from the inode and from the file data. The files names are spread out all over the disk in "directories"... Perhaps you are thinking of "NTFS", where the metadata is all kept in a single area? xfsdump isn't able to do anything special and I'm pretty sure it requires no root privileges unless the files being dumped are owned by root. Also any system attributes need root access to read, but if I rsync a disk I have to run as root anyway, or I get access errors. In my scenario, I setup xfs dump & restore with large buffers and put "mbuffer" in between them. If you run xfs with tiny buffers of 1K or so, you can probably get similar performance out of it. The key difference is buffer size and read/write size... no shortcuts are needed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org