Что не так с этой командой xargs?

Какова философия такого подхода?

Эффективность (лучшее использование характеристик диска) и производительность (позволяет приложению продолжить работу сразу после записи).

Почему данные не записываются сразу?

Основным преимуществом является то, что операционная система может свободно переупорядочивать и объединять непрерывные операции записи, чтобы улучшить использование полосы пропускания (меньше операций и меньше поисков). Жесткие диски работают лучше, когда требуется небольшое количество больших операций, в то время как приложениям, как правило, требуется большое количество небольших операций. Еще одна очевидная оптимизация заключается в том, что ОС также может удалить все записи, кроме последней, когда один и тот же блок записывается несколько раз за короткий период времени, или даже удалить некоторые записи вместе, если затронутый файл был удален за это время.

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

Нет ли опасности, что запись не удастся из-за ошибки ввода-вывода?

Не обязательно. Это зависит от используемой файловой системы и наличия избыточности. Ошибка ввода-вывода может быть безвредной, если данные можно сохранить в другом месте. Современные файловые системы, такие как ZFS, самостоятельно восстанавливают поврежденные дисковые блоки. Также обратите внимание, что ошибки ввода-вывода не приводят к сбою современных ОС. Если они происходят во время доступа к данным, они просто сообщаются затронутому приложению. Если они происходят во время доступа к структурным метаданным и подвергают файловую систему риску, она может быть перемонтирована только для чтения или сделана недоступной.

Также существует небольшой риск потери данных в случае сбоя ОС, отключения электроэнергии или аппаратного сбоя. По этой причине приложения, которые должны быть на 100% уверены, что данные находятся на диске (например, базы данных / финансовые приложения), выполняют менее эффективную, но более безопасную синхронную запись. Чтобы уменьшить влияние на производительность, многие приложения по-прежнему используют асинхронную запись, но в конечном итоге синхронизируют их, когда пользователь явно сохраняет файл (например, vim, текстовые процессоры).

С другой стороны, подавляющему большинству пользователей и приложений не требуется и не заботиться о безопасности, которую обеспечивает синхронная запись. В случае сбоя или отключения электроэнергии зачастую единственный риск - в худшем случае потерять последние 30 секунд данных. Если не задействована финансовая транзакция или что-то подобное, что потребовало бы гораздо больших затрат, чем 30 секунд их времени, огромный выигрыш в производительности (который не является иллюзией, но вполне реален), асинхронная запись позволяет значительно превзойти производительность риск.

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