На самом деле принудительная синхронизация файлов/флеш в Java

Ответ 1

Вам нужно рассказать нам больше об оборудовании и операционной системе, а также о конкретной версии Java. Как вы измеряете эту пропускную способность?

Вы правы, что force/sync вынуждает данные выводиться на физический носитель.

Здесь исходная версия копии. Компиляция с gcc 4.0 на Intel Mac должна быть чистой.

/* rawcopy -- pure C, system calls only, copy argv[1] to argv[2] */

/* This is a test program which simply copies from file to file using
 * only system calls (section 2 of the manual.)
 *
 * Compile:
 *
 *      gcc -Wall -DBUFSIZ=1024 -o rawcopy rawcopy.c
 *
 * If DIRTY is defined, then errors are interpreted with perror(3).
 * This is ifdef'd so that the CLEAN version is free of stdio.  For
 * convenience I'm using BUFSIZ from stdio.h; to compile CLEAN just
 * use the value from your stdio.h in place of 1024 above.
 *
 * Compile DIRTY:
 *
 *      gcc -DDIRTY -Wall -o rawcopy rawcopy.c
 *
 */
#include <fcntl.h>
#include <sys/types.h>
#include <sys/uio.h>
#include <stdlib.h>
#include <unistd.h>
#if defined(DIRTY)
#   if defined(BUFSIZ)
#       error "Don't define your own BUFSIZ when DIRTY"
#   endif
#   include <stdio.h>
#   define PERROR perror(argv[0])
#else
#   define CLEAN
#   define PERROR
#   if ! defined(BUFSIZ)
#       error "You must define your own BUFSIZ with -DBUFSIZ=<number>"
#   endif
#endif

char * buffer[BUFSIZ];          /* by definition stdio BUFSIZ should
                                   be optimal size for read/write */

extern int errno ;              /* I/O errors */

int main(int argc, char * argv[]) {
    int fdi, fdo ;              /* Input/output file descriptors */
    ssize_t len ;               /* length to read/write */
    if(argc != 3){
        PERROR;
        exit(errno);
    }

    /* Open the files, returning perror errno as the exit value if fails. */
    if((fdi = open(argv[1],O_RDONLY)) == -1){
        PERROR;
        exit(errno);
    }
    if((fdo = open(argv[2], O_WRONLY|O_CREAT)) == -1){
        PERROR;
        exit(errno);
    }

    /* copy BUFSIZ bytes (or total read on last block) fast as you
       can. */
    while((len = read(fdi, (void *) buffer, BUFSIZ)) > -1){
        if(len == -1){
            PERROR;
            exit(errno);
        }
        if(write(fdo, (void*)buffer, len) == -1){
            PERROR;
            exit(errno);
        }
    }
    /* close and fsync the files */
    if(fsync(fdo) ==-1){
        PERROR;
        exit(errno);
    }
    if(close(fdo) == -1){
        PERROR;
        exit(errno);
    }
    if(close(fdi) == -1){
        PERROR;
        exit(errno);
    }

    /* if it survived to here, all worked. */
    exit(0);
}

Ответ 2

На самом деле, в C вы хотите просто вызвать fsync() в дескрипторе одного файла, а не sync() (или команду "sync" ), которая сигнализирует ядру о flush всем буферам на всю систему.

Если вы strace (получая конкретный Linux), JVM, вы должны иметь возможность наблюдать за системным вызовом fsync() или fdatasync(), который делается в вашем выходном файле. Это было бы то, что я ожидал бы от вызова getFD(). sync(). Я предполагаю, что c.force(true) просто указывает на NIO, что после каждой записи следует вызывать fsync(). Может быть просто, что JVM, который вы используете, фактически не реализует вызов sync()?

Я не уверен, почему вы не заметили разницы при вызове "sync" в качестве команды: но, очевидно, после первого вызова синхронизации последующие, как правило, намного быстрее. Опять же, я был бы склонен вырваться strace (ферма на Solaris) как "что на самом деле происходит здесь?" инструмент.

Ответ 3

Рекомендуется использовать завершение целостности данных синхронизированного ввода-вывода. Однако ваш образец C использует неправильный метод. Вы используете sync(), который используется для синхронизации всей ОС.

Если вы хотите записать блоки этого одиночного файла на диск, вам нужно использовать fsync(2) или fdatasync(2) в C. Кстати: когда вы используете буферизованное stdio в C (или BufferedOutputStream или некоторый Writer в Java) перед тем, как вы синхронизируете, вам необходимо очистить оба.

Вариант fdatasync() является более эффективным, если файл не изменил имя или размер с момента синхронизации. Но это может также не перенести все метаданные. Если вы хотите написать свои собственные безопасные системы транзакций, вам понадобятся другие материалы (например, fsyncing родительский каталог).

Ответ 4

Код C может быть субоптимальным, потому что он использует stdio, а не raw OS write(). Но тогда java может быть более оптимальным, потому что он выделяет более крупные буферы?

В любом случае, вы можете доверять только APIDOC. Остальное не зависит от ваших обязанностей.

Ответ 5

(Я знаю, что это очень поздний ответ, но я столкнулся с этим потоком, выполняющим поиск в Google, и, вероятно, вы тоже оказались здесь.)

Вызов sync() в Java в одном файловом дескрипторе, поэтому только буферы, связанные с этим одним файлом, выгружаются на диск.

В C и командной строке вы вызываете sync() во всей операционной системе - так что каждый буфер файлов выгружается на диск, для всего, что делает O/S.

Чтобы быть сопоставимым, вызов C должен состоять в syncfs (fp);

На странице руководства Linux:

   sync() causes all buffered modifications to file metadata and data to
   be written to the underlying file systems.

   syncfs() is like sync(), but synchronizes just the file system contain‐
   ing file referred to by the open file descriptor fd.