Исправление DawnCaster, (текущая версия) :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию совсем, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а (она, как я понимаю, как раз и появилась по итогам обсуждений) и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - без полного sync’а - никто ничего не гарантирует от слова совсем. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было. Данные могут не касаться диска не то что часами, а целыми днями! Причём, одни файлы он пишет почти сразу (обычно большие и однократно преаллоцированные с помощью соответствующего вызова или утилиты), другие он откладывает чуть-ли не до самого от отмонтирования, пока памяти свободной достаточно.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт в идеале ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё. Я как пользователь могу быть уставшим, и забыть сделать sync. Пьяный монтёр может оторвать мне в щитке фазу в любой момент времени. Вариантов много, и «крайней» тут всегда будет ФС, поэтому она должна как минимум настраиваться либо в сторону большей надежности или скорости, я так считаю.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а (она, как я понимаю, как раз и появилась по итогам обсуждений) и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - без полного sync’а - никто ничего не гарантирует от слова совсем. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было. Данные могут не касаться диска не то что часами, а целыми днями! Причём, одни файлы он пишет почти сразу (обычно большие и однократно преаллоцированные с помощью соответствующего вызова или утилиты), другие он откладывает чуть-ли не до самого от отмонтирования, пока памяти свободной достаточно.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт в идеале ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё. Я как пользователь могу быть уставшим, и забыть сделать sync. Пьяный монтёр может оторвать мне в щитке фазу в любой момент времени. Вариантов много, и «крайней» тут всегда будет ФС, поэтому она должна как минимум настраиваться либо в сторону большей надежности или скорости, я так считаю.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а (она, как я понимаю, как раз и появилась по итогам обсуждений) и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - без полного sync’а - никто ничего не гарантирует от слова совсем. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было. Данные могут не касаться диска не то что часами, а целыми днями! Причём, одни файлы он пишет почти сразу (обычно большие и однократно преаллоцированные с помощью соответствующего вызова или утилиты), другие он откладывает чуть-ли не до самого от отмонтирования, пока памяти свободной достаточно.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а (она, как я понимаю, как раз и появилась по итогам обсуждений) и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - без полного sync’а - никто ничего не гарантирует от слова совсем. Данные могут не касаться диска не то что часами, а целыми днями! Пока памяти свободной достаточно. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а (она, как я понимаю, как раз и появилась по итогам обсуждений) и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем. Данные могут не касаться диска не то что часами, а целыми днями! Пока памяти свободной достаточно. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем. Данные могут не касаться диска не то что часами, а целыми днями! Пока памяти свободной достаточно. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит на диск файлы которые он генерирует за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем. Данные могут не касаться диска не то что часами, а целыми днями! Пока памяти свободной достаточно. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.
Исправление DawnCaster, :
однозначно проблема OO
Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит на диск файлы которые он генерирует за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем. Данные могут не касаться диска не то что часами, а целыми днями! Пока памяти свободной достаточно. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.
Исходная версия DawnCaster, :
однозначно проблема OO
Я полностью согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. И ситуация тут всё-таки не совсем однозначная, ИМХО.
С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит на диск файлы которые он генерирует за какое-то разумное время и не потеряет их на ровном месте.
Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».
В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем. Данные могут не касаться диска не то что часами, а целыми днями! Пока памяти свободной достаточно. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было.
Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё.