Факт того, что в MacOS функция fsync() работает по-другому, не как в привычном всем Linux, далеко не новость. Но многие о нем забывают. Особенной хронической формой маразма страдают авторы бенчмарков. 17 февраля Hector Martin (@marcan42) (разработчик Asahi Linux) в очередной раз подтверждает это своим постом в Твиттере.
Когда программа сохраняет информацию на диск, для особо чувствительной к потере информации программе необходимо дождаться освобождение кэша, чтобы имела место быть уверенность в том, что информация, во-первых сохранилась как факт, во-вторых сохранилась в нужном порядке. Для этого еще в первых версиях Unix была реализована функция fsync(). В линуксе эта функция реализована в glibc. По изначальному дизайну, fsync() должна возвращать результат только после полного опорожнения дискового кэша.
У разработчиков MacOS немного иной взгляд на этот процесс. Пробежавшись по манам fsync и fcntl, можно сделать выводы. По мнению Apple, опорожнение кэша может длиться слишком долго, нет необходимости ждать столько времени. Чтобы программы не морозились при сохранении данных, выполнение функции fsync() можно игнорировать. Ну а прошивка контролера диска сама разберётся, когда ей надо будет опорожнять кэш, и надо ли его опорожнять вообще.
Для чувствительным к целостности и сохранности данных существует флаг F_FULLSYNC. И он работает. Но возникает другая проблема. В таком режиме сохранение информации на собственные накопители Apple, устанавливаемые с процессорами линейки M1, происходит со скоростью около 6 Мб/сек и может проседать до 600 Кб/сек. Современные карты MicroSD подключенные через USB 2.0 работают быстрее. Сам Гектор Мартин сравнивает работу с первой попавшейся флешкой USB 3.0. Разумеется, запись на флешку происходит быстрее чем на встроенный NVMe-накопитель, ведь у флешки нет кэша. - с нотками сарказма отмечает он.
Игнорирование fsync() искусственно увеличивает мнимую производительность накопителя. Но с другой стороны это может привести к не полному сохранению данных или полному не сохранению данных в случаях перебоев подачи питания, неожиданного зависания или перезагрузки ОС, или даже простой ошибки сегментации. И тут важен не факт потери информации, а факт получаемого программой от ОС подтверждения о том, что данные были сохранены.
Hector Martin провел несколько тестов сохранения и последующими неожиданными для системы перезагрузками. И его опасения подтвердились. Сохраненный на диск файл после перезагрузки отсутствует в файловой системе.
Спустя несколько дней, другой энтузиаст Russ Bishop (@xenadu02) провел серию подобных тестов с четырьмя SSD-накопителями разных производителей. Метод тестирования довольно прост. Сразу после сохранения данных в файл с заранее заданным путём обесточивает компьютер образно выдёргиванием вилки шнура из розетки. В результате тестов два накопителя теряли данные частично или полностью, и два накопителя не теряли никаких данных на всех этапах тестирования.
Точные названия накопителей, которые сохраняли все данные:
Samsung 970 Evo Plus: MZ-V7S2T0, 2021.10
WD Red: WDS100T1R0C-68BDK0, 04Sept2021
Названия накопителей, теряющих данные:
SK Hynix Gold P31 2TB SHGP31-2000GM-2, FW 31060C20
Sabrent Rocket 512 (Phison PH-SBT-RKT-303 controller, версия ПО не указана)
Днем позже было проведено подобное испытание еще нескольких SSD-дисков, все они прошли проверку сохранив все данные:
Crucial P5 Plus 1TB CT1000P5PSSD8, FW P7CR402
Kingston SNVS/250G, 012.A005
Seagate Firecuda 530 PCIe Gen 4 1TB ZP1000GM30013, FW SU6SM001
Intel 670p 1TB, SSDPEKNU010TZ, FW 002C
Crucial P2 250GB CT250P2SSD8, FW P2CR046
Samsung 980 250GB MZ-V8V250, 2021/11/07
WD Black SN750 1TB WDS100T1B0E, 09Jan2022
WD Green SN350 240GB WDS240G20C, 02Aug2021
Не буду отнимать у читающих больше времени. Выводы предлагается делать читателю самостоятельно. Если по теоретической части есть вопросы, я буду рад стараться отвечать (на что знаю ответ).
