NSFS | versioning | copy_object - close chunkfs read stream to prevent stream being closed after stat

[nadavMiz]

Explain the changes

1. chunkfs is a Transform stream, however read_object_stream expects a write stream, so it only closes the write part. so the stream itself is still alive. it is later closed automatically (probably by garbage collector?), but this may happen after we call stat on the written file, so the mtime we stat is later modified when the stream is closed. this causes the mtime of the file to be different then that of the version. on GPFS we will not notice this until we call safe_move_posix that validates the inode and mtime of the file with the version, causing it to fail.

Issues: Fixed #8469

Testing Instructions:

1. run NC_CORETEST=true GPFS_ROOT_PATH=/ibm/fs1/tmp GPFS_DL_PATH="/usr/lpp/mmfs/lib/libgpfs.so" node ./node_modules/mocha/bin/mocha src/test/unit_tests/test_bucketspace_versioning.js on GPFS machine
2. ceph test: test_versioning_obj_suspended_copy

• Doc added/updated
• Tests added

[romayalon]

can we now add test_versioning_obj_suspended_copy? or it has issue with bucket cache still?
if it requires the bucket cache fix, please make sure you add it to #8391 (comment)

[nadavMiz]

sure I'll add it. its worth mentioning that this test is for suspended more, so will not fail in this case (in suspended mode version-id is always null and doesn't depend on mtime). the reason it failed is because the bucket cache issue, the bucket remained in enabled mode

[romayalon]

why don't we need to resume() on regular upload flow?
is there a chance on upload that the readable stream will change the xattr after we assigned the version id ?

[nadavMiz]

because in regular upload we pipe chunkfs to the source_stream, so the readable part is used, and ends on its own. while on the copy flow we use chunkfs as write stream and ignore the read part