StandardOpenOption.SYNC против StandardOpenOption.DSYNC - PullRequest
10 голосов
/ 25 ноября 2011
  1. В чем разница между StandardOpenOption.SYNC и StandardOpenOption.DSYNC ?
  2. Какой тип потери данных может произойти с DSYNC?
  3. Для каких вариантов использования подходит DSYNC?Если вы уже решили синхронизировать содержимое файла, почему вы хотите отказаться от синхронизации метаданных файла?Не будет ли относительная разница в накладных расходах незначительной?

Ответы [ 2 ]

5 голосов
/ 22 января 2012

Гиль,

DSYNC является подмножеством SYNC.

SYNC требует, чтобы все данные (данные файла и метаданные файла, управляемые файловой системой) записывались синхронно, в то время как DSYNC требует, чтобы только данные файла записывались синхронно. Что касается накладных расходов, я думаю, что это гигант "это зависит от файловой системы". Глядя на современные файловые системы, использующие такие понятия, как копирование при записи, теневое копирование, управление версиями, проверка контрольных сумм и т. Д. ... Я полагаю, что попытка блокировать всю операцию записи до тех пор, пока вся эта работа не будет выполнена, может оказаться дорогой.

Потенциал для потери данных является более запутанным ответом; Преимущества асинхронного файлового ввода-вывода состоят в том, что основная файловая система или диск могут фактически выполнять пакетную запись или упорядочивать записи, чтобы избежать случайного ввода-вывода и структурировать записи более последовательным образом.

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

Короче говоря, порядок выглядит так:

  1. (опция отсутствует) - самая быстрая, потенциальная возможность потери данных файла и мета-файла из-за 1 или более ожидающих записей, которые еще не были сброшены.
  2. DSYNC - медленнее, ждет, пока данные файла будут записаны, и вернется (давайте сохраним мета файла позже)
  3. SYNC - медленнее, ждет, пока будут записаны как данные файла, так и мета файла, и перед возвратом поднимите большие пальцы.

Я должен сказать, что я предполагаю, что все эти вопросы относятся к новому AsynchronousFileChannel в Java 7; мои извинения, если это не так.

3 голосов
/ 29 июня 2016

Вот ответ, специфичный для файловой системы Linux.

Согласно источнику для sun.nio.fs.UnixChannelFactory, эти параметры отображаются соответственно для параметров O_SYNC и O_DSYNC open(), документация которых гласит:

В документации для fdatasync(2) затем прямо указывается, что все несущественное для извлечения данных файла, такое как время последнего доступа и время последнего изменения , не сбрасывается O_DSYNC, но все, что есть, это:

fsync () передает ("сбрасывает") все измененные данные в ядре (т.е. изменен буферный кеш страниц для) файла, на который ссылается файл дескриптор fd к дисковому устройству (или другому постоянному запоминающему устройству) так что вся измененная информация может быть получена даже после система упала или была перезагружена. ... Звонок блокируется до устройства сообщает, что передача завершена. Также сбрасывает метаданные информация, связанная с файлом (см. stat (2)).

fdatasync () аналогичен fsync (), но не сбрасывает измененные метаданные, если только эти метаданные не нужны для последующий поиск данных должен быть правильно обработан. Например, изменяется на st_atime или st_mtime (соответственно, время последнего доступа и время последней модификации; см. stat (2)) не требует промывки потому что они не являются необходимыми для последующего чтения данных, чтобы быть обрабатывается правильно. С другой стороны, изменение размера файла (st_size, как сделано, скажем, ftruncate (2)), потребует метаданных вровень.

Таким образом, обоснованное предположение таково, если программа не использует эти атрибуты, не важные для данных (и важна синхронизация их значений). StandardOpenOption.DSYNC приемлемо. (Хотя я не уверен, сколько практических преимуществ можно получить при выборе DSYNC вместо SYNC.)

Просматривая BasicFileAttributes, такие поля, как creationTime(), lastModifiedTime(), lastAccessTime(), вероятно, попадают в эту категорию "не важно для доступа к данным", тогда как такие поля, как isDirectory(), isRegularFile(), is*() и size(), вероятно, не будут, поскольку я не могу представить, что данные доступны, если они неверны.

...