[lustre-discuss] lfs_migrate rsync vs. lfs migrate and layout swap

Dauchy, Nathan (ARC-TNC)[CSRA, LLC] nathan.dauchy at nasa.gov
Sun Nov 19 10:31:01 PST 2017


I'm trying to clarify and confirm the differences between lfs_migrate's use of rsync vs. "lfs migrate".  This is in regards to performance, checksumming, and interrupts.  Relevant code changes that introduced the two methods are here:

The quick testing I have done is with a 8GB file with stripe count of 4, and included the patch to lfs_migrate from:
(and client cache was dropped between each test)

$ time ./lfs_migrate -y bigfile
real    1m13.643s

$ time ./lfs_migrate -y -s bigfile
real    1m13.194s

$ time ./lfs_migrate -y -f bigfile
real    0m31.791s

$ time ./lfs_migrate -y -f -s bigfile
real    0m28.020s

* Performance:  The migrate runs faster when forcing rsync (assuming multiple stripes).  There is also minimal performance benefit to skipping the checksum with the rsync method.  Interestingly, performance with "lfs migrate" as the backend is barely effected (and within the noise when I ran multiple tests) by the choice of checksumming or not.  So, my question is whether there is some serialization going on with the layout swap method which causes it to be slower?

* Checksums:  In reading the migrate code in lfs.c, it is not obvious to me that there is any checksumming done at all for "lfs migrate".  That would explain why there is minimal performance difference.  How is data integrity ensured with this method?  Does the file data version somehow capture the checksum too?

* Interrupts:  If the rsync method is interrupted (kill -9, or client reboot) then a ".tmp.XXXXXX" file is left.  This is reasonably easy to search for and clean up.  With the lfs migrate layout swap method, what happens to the "volatile file" and it's objects?  Is an lfsck required in order to clean up the objects?

At this point, the "old" method seems preferable.  Are there other benefits to using the lfs migrate layout swap method that I'm missing?

Thanks for any clarifications or other suggestions!


More information about the lustre-discuss mailing list