| Message ID | 20220420083653.1031631-2-zlang@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | several long time unmerged patches from zlang | expand |
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 >
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); res = fstat(fd, &stbuf); if (res == -1)
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(+)