How much time sync() can take at max?

Question

sync() causes all pending modifications to filesystem metadata and cached file data to be written to the underlying filesystems. sync() is always successful.

it means sync() will return only after syncing all the data to underline file system. I am wondering how much time it can take to sync() all the data? Can it be in several minutes or hours at worst.

I don't know what parameter defines sync() time.

I have created a test program using sync()

#define _LARGEFILE64_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

char buffer[536870912];

int main(void)
{
        int fd;
        loff_t nr = 536870912;
        int ret;

        remove("./dummy");
        errno = 0;
        fd = open("./dummy", O_CREAT | O_NOFOLLOW | O_LARGEFILE | O_RDWR, 0700);
        perror("open");

        buffer[10] = 'a';
        buffer[1024] = 'b';
        buffer[10000] = 'c';
        buffer[536870912 - 1000] = 'd';
        buffer[536870912 - 2000] = 'e';
        buffer[536870912 - 1] = 'f';
        int i = 3;
        while (i-- > 0) {
                ret = write(fd, buffer, 536870912);
                if (ret <= 0) {
                        perror("write");
                        return 1;
                }
                nr -= ret;
                printf("sync start\n");
        }
        sync();
        printf("sync done\n");
        return 0;
}

It shows uneven time taken by sync() in multiple iterations.

Sometimes this test program takes even 30 mins at sync() ie sync() does not return for 30 mins. Is it a valid behaviour?

Any help will be appreciated.

Answer 1

Max forever. eg data waiting to be written to a disconnected NFS share.

Answer 2

POSIX says :

The writing, although scheduled, is not necessarily complete upon return from sync().

That means that in general sync() just schedules the flush but do not wait for its completion. So sync() is almost asynchronous and that the fact that it returns doesn't means that the flush has been made. There is no relation in between time consumed by sync() call to the underlying flush. Neither you will be able to know if flushing was successful/terminated or not.

Answer 3

There is no fixed upper limit on the amount of time that sync() may take to execute. Its task is to sync modifies pages in the buffer cache to the underlying filesystems. How much time that takes depends on (among other factors): how much data there is to sync, and how slow the devices are that host the underlying fileysystems (think, for example, of a USB stick that has very low write speeds). In the extreme, this might be many tens of minutes, or even hours.

The accepted answer quotes this detail from POSIX:

The writing, although scheduled, is not necessarily complete upon return from sync().

But then interprets this to mean:

That means that in general sync() just schedules the flush but do not wait for its completion.

I think this misunderstands POSIX and also the nature of existing implementations. In most existing (perhaps all modern) implementations, sync() blocks until all data has been synced to the storage devices. Thus, by the time sync() returns, the application knows that the data has reached the underlying storage.

However, the POSIX specification also permits an alternative implementation: the kernel merely schedules the sync operation to occur asynchronously and returns from the sync() call straight away. This is obviously less useful than the blocking sync() implementation, since an application performing a sync operation typically would like to know when the data has reached the underlying device(s). On systems with "asynchronous" sync() , the application can't determine when the data has landed on the storage device(s).

POSIX permits either style of implementation presumably because at the time the API was standardized, some existing implementation(s) provided the weaker asynchronous sync() implementation, and the usual POSIX approach in such cases is to standardize to the lowest common denominator.