Bug #18661
closed
2017-01-17 09:28:32.263766 7f0a7f5d4700 10 client.4432 send_request client_request(unknown.0:9 create #1/open_file 2017-01-17 09:28:32.263717) v3 to mds.0
...
2017-01-17 09:28:34.417892 7f0a7fdd5700 10 client.4432 send_request client_request(unknown.0:11 unlink #1/open_file 2017-01-17 09:28:34.417762) v3 to mds.0
...
2017-01-17 09:28:34.462320 7f0a7fdd5700 10 client.4432 send_request client_request(unknown.0:13 create #1/open_file 2017-01-17 09:28:34.462246) v3 to mds.0
def test_open_inode(self):
"""
That the case of a dentry unlinked while a client holds an
inode open is handled correctly.
The inode should be moved into a stray dentry, while the original
dentry and directory should be purged.
The inode's data should be purged when the client eventually closes
it.
"""
mount_a_client_id = self.mount_a.get_global_id()
# Write some bytes to a file
size_mb = 8
self.mount_a.write_n_mb("open_file", size_mb)
open_file_ino = self.mount_a.path_to_ino("open_file")
# Hold the file open
p = self.mount_a.open_background("open_file")
self.assertEqual(self.get_session(mount_a_client_id)['num_caps'], 2)
# Unlink the dentry
self.mount_a.run_shell(["rm", "-f", "open_file"])
seems like the background open was executed after unlink
- Status changed from New to 12
You're right, that piece of test code is racy :-/ Need to get the remote python code running inside open_background to signal somehow when it opens the file, and have the test code block until then.
- Status changed from 12 to Fix Under Review
- Backport set to kraken,jewel
- Status changed from Fix Under Review to Pending Backport
- Status changed from Pending Backport to Resolved
Also available in: Atom
PDF