Linux гарантирует, что содержание файла сбрасывается к диску после близко ()?
У меня есть как это сделать в php, но я не знаю, как оптимизировать код. Кто-нибудь знает, как это сделать правильно?
<?php
$z = 3;
$dimension = (2 * $z) -1 ;
for($i = 1; $i <= $dimension; $i++)
{
for($j = 1; $j <= $dimension; $j++)
{
if(($i == 1|| $j == 1) || ($i == $dimension || $j == $dimension)){
echo $z . " ";
} else if(($i == 2 || $j == 2) || ($i == $dimension - 1 || $j == $dimension - 1)){
echo $z - 1 . " ";
}
else if(($i == 3 || $j == 3) || ($i == $dimension - 2 || $j == $dimension - 2)){
echo $z - 2 . " ";
}
else if(($i == 4 || $j == 4) || ($i == $dimension - 3 || $j == $dimension - 3)){
echo $z - 3 . " ";
}
else{
echo $z - 4 . " ";
}
if($j == $dimension){
echo "</br>";
}
}
}
?>
7 ответов
От"man 2 close":
Успешное завершение не гарантирует, что данные были успешно сохранены на диск, поскольку ядро задерживает записи.
В странице справочника говорится, что, если Вы хотите быть уверенными, что Ваши данные находятся на диске, необходимо использовать fsync () сами.
Нет, близко не выполняет fsync (2) и избил бы до смерти много машин, если он сделал так. Много промежуточных файлов открыты и закрыты их создателем, затем открылись и закрылись их потребителем, затем удаленным, и эта очень общая последовательность потребовала бы касания диска, если бы близко (2) выполнил автоматический fsync (2). Вместо этого диск обычно не затрагивается, и диск никогда не знает, что файл был там.
Также важно отметить, что fsync не гарантирует, что файл находится на диске; это просто гарантирует, что ОС попросила, чтобы файловая система сбросила изменения в диске. Файловая система ничего не должна писать в диск
Если
_POSIX_SYNCHRONIZED_IOне определяется, формулировка полагается в большой степени на документ соответствия, чтобы сказать пользователю, что может ожидаться от системы. Явно предназначается, что пустая реализация разрешена.
К счастью все общие файловые системы для Linux действительно на самом деле пишут изменения в диске; к несчастью это все еще не гарантирует, что файл находится на диске. Много жестких дисков идут с включенной буферизацией записи (и поэтому имейте их собственные буферы, которые fsync не сбрасывает). И некоторые диски/RAID-контроллеры даже лгут Вам о том, что сбросили их буферы.
Нет. fclose () не подразумевает fsync (). Много файловых систем Linux задерживает записи и обрабатывает их в пакетном режиме, который улучшает общую производительность, по-видимому, уменьшает износ дисковода и улучшает ресурс аккумулятора для ноутбуков. Если бы ОС должна была записать в диск каждый раз, когда файл закрылся, многие из этих преимуществ были бы потеряны.
Paul Tomblin упомянул противоречие в своем ответе и объяснение того, которое я видел, не впишется в комментарий. Вот то, что я услышал:
Недавнее противоречие по упорядочиванию ext4 (ext4, предложенный преемник популярной файловой системы ext3 Linux). Это обычно, в системах Linux и Unix, для изменения важных файлов путем чтения старого, выписывания нового с другим именем и переименования нового к старому. Идея состоит в том, чтобы гарантировать, что или новый или старый будут там, даже если система перестанет работать в какой-то момент. К сожалению, ext4, кажется, рад считать старый, переименовать новый к старому и записать новый, который может быть настоящей проблемой, если система понижается между шагами 2 и 3.
Стандартный способ иметь дело с этим, конечно, fsync (), но та производительность мусора. Действительное решение состоит в том, чтобы изменить ext4 для хранения упорядочивания ext3, где это не переименовало бы файл, пока это не закончило выписывать его. По-видимому, это не охвачено стандартом, таким образом, это - качество проблемы реализации, и QoI ext4 действительно паршив здесь, там не будучи никаким способом надежно записать новую версию конфигурационных файлов, постоянно не звоня fsync (), со всеми проблемами, который вызывает, или рискующий теряющий обе версии.
Нет, это не гарантируется. ОС имеет свое собственное кэширование. Все завершение действительно гарантирует, то, что буферы программ сбрасываются к ОС, но ОС может все еще содержать на него незаписанный. Я полагаю, что существует некоторое противоречие в мире ядра Linux, потому что даже fsync не гарантирует, что это сбрасывается к диску, по крайней мере, в ext3.
Можно также интересоваться этим отчетом об ошибках от firebird sql база данных относительно fcntl (O_SYNC) не работающий над Linux.
Кроме того, вопрос, который Вы задаете, подразумевает потенциальную проблему. Что Вы подразумеваете под записью в диск?Какое это имеет значение? Вы обеспокоены, что питание выходит, и файл отсутствует в диске? Почему бы не использовать UPS в системе или SAN?
В этом случае Вам нужна файловая система журналирования - и не только метаданные, журналирующие файловую систему, но и полный журнал даже для всех данных.
Даже в этом случае необходимо понять, что помимо O/S's involvment, большинство жестких дисков лжет Вам о выполнении fsync. - fsync просто отправляет данные на диск, и это до отдельной операционной системы, чтобы знать, как ожидать диска сбросить его собственные кэши.
- jeffk ++
Я не думаю, что Linux может гарантировать это, так как сам диск может кэшировать данные также.