mtime in .snap directory is not stable #4071
Labels
Comments
xhernandez
added a commit
to xhernandez/glusterfs
that referenced
this issue
Mar 24, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: gluster#4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
xhernandez
added a commit
that referenced
this issue
Mar 24, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: #4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
xhernandez
added a commit
to xhernandez/glusterfs
that referenced
this issue
Mar 27, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: gluster#4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
xhernandez
added a commit
to xhernandez/glusterfs
that referenced
this issue
Mar 27, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: gluster#4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
xhernandez
added a commit
to xhernandez/glusterfs
that referenced
this issue
Mar 27, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: gluster#4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
Shwetha-Acharya
pushed a commit
that referenced
this issue
Mar 29, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: #4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
Shwetha-Acharya
pushed a commit
that referenced
this issue
Apr 4, 2023
In the previous implementation, when the mtime, ctime and atime of an snapshot virtual directory was requested, the returned time was the current time. Apparently, the old versions of kernel's nfs client did ignore this change during a readdir operation. However, newer versions are checking it and retrying the whole readdir operation when these times differ from the previous request (I guess that it assumes that the directory contents have been changed and tries to get the new contents). This causes a long delay or even an infinite loop. The optimal change would be to keep the time of modification and changes in the inode context of the virtual directories to always return stable and consistent data, but this requires a significant amount of changes. For now, just return a constant value for these specific entries. Fixes: #4071 Signed-off-by: Xavi Hernandez <xhernandez@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The mtime, ctime and atime of the
.snapvirtual directory and its contents where the available snapshots can be accessed are not stable. They change each time a request is sent, even if it's a read only operation like astat.This will constantly invalidate cache contents in Gluster but in some cases, like NFS clients, this will cause a worse problem because a change in mtime while reading the directory contents causes the nfs client to retry the readdir.
This causes an infinite loop when an ls is done from a recent linux kernel nfs client on
.snapdirectory.The text was updated successfully, but these errors were encountered: