Цитата(kurtis @ Nov 5 2012, 13:44)
2. sync() сливает содержимое буферов ядра, в буфер устройства. Но это никак не влияет на надежность, т.к. если данные попали в буфер устройства, то не факт что они попали на физический носитель.
Увы, данное ложное утверждение повлекло за собой бла бла бла, а не обсуждение. Дело в том,
что sync() не только сбрасывает ядерные буфера в устройство, но еще дает команду устройству
сбросить свои кеши. Но есть два нюанса.
Первый - устройство может обмануть и сказать что кеши сброшены, хотя это не так (не говоря
уже о том, что такой команды для данного типа устройств может не быть). Например,
спецификация ATA определяет команду FLUSH_CACHE (0xe7) как mandatory, но это не мешает
дешевым/кривым дискам врать. Плюс, кеши могут сбрасываться в измененном порядке, алгоритмы
внутреннего хранения данных могут накладывать свой отпечаток и т.д. - это тоже важно.
Второй нюанс заключается в том, что sync() сбрасывает ядерные буфера на уровне блочных устройств,
а ведь еще могут быть буфера ФС и даже в пользовательском пространстве существует буферизация. Для
решения этой проблемы есть fflush().
Таким образом, чтобы данные файла гарантированно оказались на диске (не кривом), нужно выполнить
комбинацию fwrite(); fflush(); fsync(); Несложно заметить, что это не решает проблему ТС, т.к.
пропадание питания во время этой последовательности может привести (и приведет) к порче данных/ФС.
Поэтому единственным выходом является использование специальных файловых систем (журналируемых или
log-based). Например, те же ext3/ext4 позволяют журналировать не только метаданные, но и данные,
хоть и с потерей производительности (причем практически двукратной, т.к. данные сначала пишутся
в журнал, а потом еще раз в "обычное" место; впрочем, некоторые ФС - ZFS, Btrfs, .. - используют
COW и данные пишутся один раз, но у них присутствуют другие недостатки). Для совсем "голых" устройств
есть jffs2, logfs и т.д.
Разумеется, эти ФС требуют, чтобы диски умели честно сбрасывать свои кеши. Диски с вращающимися
блинами также любят переупорядочивать запись кешей чтобы лишний раз не гонять головки. Но для ФС
порядок записи данных и метаданных очень важен, поэтому с этим тоже нужно бороться (курим маны на
ext3/4, термин barrier).
Для SSD (и других девайсов на флеше типа Compact Flash) все еще печальнее из-за статического
wear-leveling`а и прочих наворотов вроде представления данных как сжатого архива внутри девайса
(поэтому на некоторых новых контроллерах SSD рекомендуется не использовать TRIM во избежание
потери производительности/повышения износа).
Подобные проблемы не решаются на уровне ОС, т.к. все это делается прозрачно для нее внутри логики
девайсов. Ушлые производители об этом знают, поэтому выпускают линейки "надежных" power-safe дисков
(втридорога, разумеется), а в потребительскую продукцию внедрять новые технологии не спешат
В двух словах примерно так...
Возвращаясь к вопросам ТС.
1. mmap() не будет быстрее read/write, т.к. все пойдет через один механизм (VFS и page cache).
2. Следует использовать журналируемую ФС и правильные диски. Неплохим стартом будет ext3/4 с
журналированием данных + HDD поддерживающий спецификацию ATA8 и выше.
3. Лучше делать много файлов из расчета что при сбое потеряются данные последнего файла. Т.е. если
вы готовы потерять последнюю минуту - делайте файлы на каждую минуту на каждый канал. Если вы вообще
не готовы терять данные - тоже решается, но сложнее.
Также старайтесь всегда дописывать данные в файл (append) а не писать в середину.
Вопрос как записать "важный для системы параметр размером ну в 256 байт" чаще решается иными методами.
Например, "голый" (т.е. без внутренней логики) NAND + logfs, а если параметр небольшой - то EEPROM
или вообще FRAM с зиллионом циклов чтения/записи + правильная структура хранения данных (т.е. вообще
без ФС). Батарейка/ИБП тоже вариант, да.
Буферирование потока данных в файл, Идеи, критика
Nov 3 2012, 13:21
