-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CephFS: Failure in smb2.timestamps.time_t_* #71
Comments
source4/torture/smb2/timestamps.c:
Running test samba3.smb2.timestamps.time_t_1968
|
Checking vfs_defaultfs:
|
I was looking into the extra failures with cephfs.vfs for which I have identified a possible fix. |
!3553 should fix the difference in test failures. |
Thanks @anoopcs9, I tested the patch out in my devel environment and can confirm that the patch indeed fixes the problem seen on ceph_vfs module. However there is also a problem seen with write times. This same problem is also seen with ceph-fuse mounts. I therefore think that this is an issue with CephFS. I am working on writing a reproducer to recrete the issue without samba. cephfs_vfs:
cephfs-fuse:
|
And if I remember correctly I have seen mismatch with change_time also while running smb2.timestamps.time_t-1_. |
A simple c program to test the setting of timespec.
Compile above with the following command
The changed timespec is as per what we have set with ceph_futimens. ie. This doesn't recreate the problem we expected to see. Will look at what sama is doing in closer detail to investigate further. |
I just took a closer look at vfs_ceph.c and realised that we never call ceph_futimens(). We instead call ceph_setattrx() and never really set the time on this fd.
|
Taking a closer look at the smbtorture test static bool test_time_t(struct torture_context *tctx, //Open file Causing a failure in line 250. It seems to be receiving the wrong information the second time. We need to understandwhy. If you look at the output of the test, we see the following lines The second line is from the second getinfo() call. |
With this new reproducer, the problem now appears to be because of limitations of the ceph filesystem. Given below is a reproducer which sets and gets the mtimes for files both on a ceph filesystem and a local filesystem.
The results are as follows
The time being set and the resultant times returned do not match. |
@synarete pointed out that the fields used to store the time variables in the ceph code are u32 which wouldn't work very well for the values we are setting. So we decided to test out with UINT32_MAX values.
and the results are as follows
|
Using |
reported with cephfs at |
Above change got finally merged after few back and forth discussions.
Considering the low priority given for the above tracker we can now safely put the following into flapping.cephfs with a link to it:
|
@synarete, You will probably need to backport this to the cephfs-ll VFS plugin. |
While adding new smbtorture tests in PR #65, we have come across a few failures. This particular issue deals with the failures in the smb2.timestamps.time_t* tests.
cephfs: (fuse mount)
samba3.smb2.timestamps.time_t_15032385535
samba3.smb2.timestamps.time_t_10000000000
samba3.smb2.timestamps.time_t_-1
samba3.smb2.timestamps.time_t_-2
samba3.smb2.timestamps.time_t_1968
cephfs.vfs: (vfs mount)
samba3.smb2.timestamps.time_t_15032385535
samba3.smb2.timestamps.time_t_10000000000
samba3.smb2.timestamps.time_t_4294967295
samba3.smb2.timestamps.time_t_1
samba3.smb2.timestamps.time_t_0
samba3.smb2.timestamps.time_t_-1
samba3.smb2.timestamps.time_t_-2
samba3.smb2.timestamps.time_t_1968
samba3.smb2.timestamps.freeze-thaw
The text was updated successfully, but these errors were encountered: