Re: [PATCH 1/4] src/t_rename_overwrite: fsync to flush the rename operation result

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Apr 20, 2022 at 04:36:50PM +0800, Zorro Lang wrote:
> The generic/035 fails on glusterfs due to glusterfs (or others like
> it), the file state can't be updated in time in client side, there's
> time delay. So call fsync to get the right file state after rename.
> 
> Signed-off-by: Zorro Lang <zlang@redhat.com>
> ---
>  src/t_rename_overwrite.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/t_rename_overwrite.c b/src/t_rename_overwrite.c
> index c5cdd1db..8dcf8d46 100644
> --- a/src/t_rename_overwrite.c
> +++ b/src/t_rename_overwrite.c
> @@ -2,6 +2,7 @@
>  #include <fcntl.h>
>  #include <err.h>
>  #include <sys/stat.h>
> +#include <unistd.h>
>  
>  int main(int argc, char *argv[])
>  {
> @@ -25,6 +26,7 @@ int main(int argc, char *argv[])
>  	res = rename(path1, path2);
>  	if (res == -1)
>  		err(1, "rename(\"%s\", \"%s\")", path1, path2);
> +	fsync(fd);

The callsite needs error checking, right?

Also, what's going on with glusterfs?  We unlinked path2 from its parent
directory, which means that it's now an unlinked open file.  The next
code chunk in this file checks st_nlink != 0.  Does the fsync force the
operation to the server so that the fstat call pulls data from the
server?  Or put another way, does the fstat call return stale stat data
after a rename?

--D

>  
>  	res = fstat(fd, &stbuf);
>  	if (res == -1)
> -- 
> 2.31.1
>