- это редактирование файлов в Linux, непосредственно сохраненным на диске?
Вам нужно использовать $ {id [@]} , чтобы указать все элементы массива id :
$ for i in "${id[@]}"; do echo "This is "${header["$i"]}""; done
This is X Value
This is Y Value
This is Z Value
Пока вы получаете только первый элемент, используя $ id :
$ for i in "$id"; do echo "This is "${header["$i"]}""; done
This is X Value
if I turn off the computer immediately after I edit and save a file, my changes will be most likely lost?
Может быть. Я бы не сказал «скорее всего», но вероятность зависит от многих вещей.
Простой способ повысить производительность записи файлов состоит в том, чтобы ОС просто кэшировала данные, (солгала )приложению, через которое была выполнена запись, а затем фактически выполнила запись позже. Это особенно полезно, если в это же время происходит другая активность диска :, операционная система может расставить приоритеты при чтении и позже выполнить запись. Это также может полностью устранить необходимость фактической записи, например, в случае, когда временный файл впоследствии быстро удаляется.
Проблема с кэшированием становится более заметной, если хранилище работает медленно. Копирование файлов с быстрого SSD на медленную флешку, вероятно, потребует много кэширования записи, поскольку флешка просто не поспевает. Но ваша команда cpвозвращает результат быстрее, поэтому вы можете продолжить работу, возможно, даже отредактировав только что скопированные файлы.
Конечно, у такого кэширования есть недостаток, который вы заметили: некоторые данные могут быть потеряны до того, как они будут фактически сохранены. Пользователь будет раздражен, если его редактор скажет ему, что запись прошла успешно, но на самом деле файла нет на диске. Вот почему существует системный вызовfsync(), который должен возвращаться только после того, как файл попал на диск. Ваш редактор может использовать это, чтобы убедиться, что данные в порядке, прежде чем сообщать пользователю об успешной записи.
Я сказал «должно быть», поскольку сам диск может солгать ОС и сказать, что запись завершена, в то время как файл на самом деле существует только в энергозависимом кэше записи внутри диска. В зависимости от привода,может быть нет никакого способа обойти это.
В дополнение к fsync()существуют также системные вызовы sync()и syncfs(), которые просят систему убедиться, что все системные -операции записи или все операции записи в конкретной файловой системе попали на диск. Для их вызова можно использовать утилиту sync.
Кроме того, есть также флагO_DIRECTдля open(), который должен «пытаться свести к минимуму эффекты кэширования операций ввода-вывода в этот файл и из него». Удаление кэширования снижает производительность, поэтому оно в основном используется приложениями (базами данных ), которые сами кэшируют и хотят контролировать его.(O_DIRECTне без проблем, комментарии по этому поводу на справочной странице несколько забавны.)
То, что происходит при отключении питания -, также зависит от файловой системы. Вас должны беспокоить не только данные файла, но и метаданные файловой системы. Иметь данные файла на диске бесполезно, если вы не можете его найти. Просто расширение файла до большего размера потребует выделения новых блоков данных, и их нужно где-то пометить.
То, как файловая система обрабатывает изменения метаданных и порядок между метаданными и записью данных, сильно различается. Например, с ext4, если вы установите флаг монтирования data=journal, тогда все записи — даже записи данных — проходят через журнал и должны быть достаточно безопасными. Это также означает, что они записываются дважды, поэтому производительность снижается. Параметры по умолчанию пытаются упорядочить записи таким образом, чтобы данные были на диске до того, как будут обновлены метаданные. Другие параметры или другая файловая система могут быть лучше или хуже; Я даже не буду пытаться всесторонне изучить.
На практике в малонагруженной системе файл должен появиться на диске в течение нескольких секунд. Если вы имеете дело со съемным хранилищем, размонтируйте файловую систему, прежде чем извлекать носитель, чтобы убедиться, что данные действительно отправляются на диск, а дальнейшая активность отсутствует. (Или попросите сделать это за вас.)
Это правда, что большинство операционных систем, включая Unix, Linux и Windows, используют кэш записи для ускорения операций. Это означает, что выключать компьютер, не выключая его, — плохая идея и может привести к потере данных. То же самое верно, если вы извлекаете USB-накопитель до того, как он будет готов к извлечению.
В большинстве систем также предусмотрена возможность синхронной записи. Это означает, что данные будут на диске до того, как приложение получит подтверждение об успешном выполнении за счет замедления.
Короче говоря, есть причина, по которой следует правильно выключить компьютер и должным образом подготовить USB-накопитель к извлечению.
Существует чрезвычайно простой способ доказать, что не может быть правдой то, что изменения файлов всегда сохраняются непосредственно на диск, а именно тот факт, что существуют файловые системы, которые не в первую очередь не поддерживается диском . Если файловая система вообще не имеет диска, то она не может записать изменения на диск, никогда .
Некоторые примеры::
tmpfs, файловая система, которая существует только в оперативной памяти (или, точнее, в буферном кеше)ramfs, файловая система, существующая только в оперативной памяти- любая сетевая файловая система (NFS, CIFS/SMB, AFS, AFP, …)
- любая виртуальная файловая система (
sysfs,procfs,devfs,shmfs, …)
Но даже для дисковых -файловых систем это обычно неверно. На страницеHow To Corrupt An SQLite Database есть глава под названием Ошибка синхронизации , в которой описывается множество различных способов записи (в этом случае фиксации в базе данных SQLite ). не приходят на диск. У SQLite также есть технический документ, объясняющий, через что вам нужно пройти, чтобы гарантироватьAtomic Commit In SQLite. (Обратите внимание, что Атомарная запись гораздо сложнее, чем просто Запись ,но, конечно, запись на диск — это под-проблема атомарной записи, и вы можете многое узнать об этой проблеме из этой статьи. )В этом документе есть разделЧто может пойти не так , который включает подраздел оНеполной очистке диска , в котором приведены некоторые примеры тонкостей, которые могут помешать записи на диск. (например, когда контроллер жесткого диска сообщает, что он записал на диск, хотя на самом деле это не так — да, есть производители жестких дисков, которые делают это, и это может даже быть законным в соответствии со спецификацией ATA, потому что это неоднозначно сформулировано. в этом отношении ).
В слабонагруженной системе ядро позволяет новым -записанным данным файла находиться в кэше страницы -примерно 30 секунд после write()перед сбросом на диск, чтобы оптимизировать для случая, когда он будет удален или изменен снова в ближайшее время.
В Linux dirty_expire_centisecsзначение по умолчанию равно 3000 (30 секунд)и определяет, сколько времени должно пройти до «истечения срока действия» новых -записанных данных. (См. https://lwn.net/Articles/322823/).
См.https://www.kernel.org/doc/Documentation/sysctl/vm.txtдля получения дополнительных настроек, а также Google для получения дополнительной информации. (напр. погуглитеdirty_writeback_centisecs).
Значение по умолчанию для /proc/sys/vm/dirty_writeback_centisecsв Linux: 500 (5 секунд ),и PowerTop рекомендует установить его на 1500 (15 секунд ), чтобы снизить энергопотребление.
Отложенная запись -обратной записи также дает ядру время, чтобы увидеть, насколько большим будет файл, прежде чем начать запись на диск. Файловые системы с отложенным выделением (, такие как XFS и, возможно, другие в наши дни ), даже не выбирают, куда на диске поместить вновь -записанные данные файла, пока это не потребуется, отдельно от выделения места для самого индексного дескриптора. Это уменьшает фрагментацию, позволяя, например, не размещать начало большого файла в промежутке в 1 мегабайт между другими файлами.
Если записывается много данных, то обратная запись на диск может быть инициирована пороговым значением того, сколько грязных (еще не синхронизированных с диском )данных может находиться в кэше страниц.
Однако, если вы больше ничего не делаете, индикатор активности жесткого диска -не загорится в течение 5 (или 15 )секунд после нажатия кнопки «Сохранить небольшой файл».
Если ваш редактор использовал fsync()после записи файла, ядро немедленно запишет его на диск. (И fsyncне вернется до тех пор, пока данные не будут фактически отправлены на диск ).
Кэширование записи внутри диска также может быть проблемой, но обычно диски пытаются передать свой кэш записи -в постоянное хранилище как можно скорее, в отличие от алгоритмов кэширования страницы -Linux. Кэш записи на диск — это скорее буфер хранения для поглощения небольших всплесков записи, но, возможно, также для задержки записи в пользу чтения и предоставления пространства встроенного ПО диска для оптимизации шаблона поиска (, например. сделайте две близлежащие записи или чтения вместо одной, затем ищите далеко, затем ищите назад.)
На вращающемся (магнитном )диске вы можете увидеть несколько задержек поиска от 7 до 10 мс каждая, прежде чем данные из команды записи SATA будут действительно защищены от отключения питания -, если были ожидающие чтения /пишет перед вашей записью.(В некоторых других ответах на этот вопрос содержится более подробная информация о кэшах записи на диск и барьерах записи, которые журналируемые ФС могут использовать для предотвращения повреждения.)
1. Память на основе флэш-памяти -
Does it depend upon the disk type (traditional hard drives vs. solid-state disks) or any other variable that I might not be aware of? Does it happen (if it does) only in Linux or is this present in other OSes?
Когда у вас есть выбор, вы не должны допускать, чтобы хранилище на основе флэш-памяти -отключалось без корректного завершения работы.
На недорогих -накопителях, таких как SD-карты, можно ожидать потери целых стираемых -блоков (, в несколько раз превышающих 4 КБ ), с потерей данных, которые могут принадлежать другим файлам или важным структурам памяти. файловая система.
Некоторые дорогие твердотельные накопители могут претендовать на более высокие гарантии в случае сбоя питания. Однако сторонние испытания -показывают, что многие дорогие твердотельные накопители этого не делают. Слой, который переназначает блоки для «выравнивания износа», является сложным и запатентованным. Возможные сбои включают потерю всех данных на диске.
Applying our testing framework, we test 17 commodity SSDs from six different vendors using more than three thousand fault injection cycles in total. Our experimental results reveal that 14 of the 17 tested SSD devices exhibit surprising failure behaviors under power faults, including bit corruption, shorn writes, unserializable writes, metadata corruption, and total device failure.
2017:https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat
2. Вращающиеся жесткие диски
Вращающиеся жесткие диски имеют разные характеристики. В целях безопасности и простоты я рекомендую исходить из того, что они имеют такую же практическую неопределенность, как и хранилища на основе флэш-памяти -.
Если только у вас нет конкретных доказательств, которых у вас явно нет. У меня нет сравнительных данных для вращающихся жестких дисков.
На жестком диске может остаться один не полностью записанный сектор с неверной контрольной суммой, что позже приведет к ошибке чтения. Вообще говоря, такой режим отказа жестких дисков вполне ожидаем; родные файловые системы Linux разработаны с учетом этого. Они стремятся сохранить контракт fsync()перед лицом этого типа потери мощности. (Нам бы очень хотелось, чтобы это гарантировалось на твердотельных накопителях ).
Однако я не уверен, что файловые системы Linux достигают этого во всех случаях и возможно ли это вообще.
При следующей загрузке после такого типа ошибки может потребоваться восстановление файловой системы. Поскольку это Linux, возможно, что восстановление файловой системы задаст некоторые вопросы, которые вы не понимаете, где вы можете только нажать Y и надеяться, что он разберется сам.
2.1 Если вы не знаете, что такое контракт fsync ()
Контракт fsync ()является источником как хороших, так и плохих новостей. Сначала вы должны понять хорошие новости.
Хорошие новости:fsync()хорошо -задокументированы как правильный способ записи файловых данных, т.е. когда вы нажмете «сохранить». И широко известно, что, например. текстовые редакторы должны атомарно заменять существующие файлы с помощью rename(). Это сделано для того, чтобы вы всегда либо сохраняли старый файл, либо получали новый файл (, который был fsync()отредактирован до переименования ). Вы же не хотите остаться с половинчатой -написанной версией нового файла.
Плохая новость :В течение многих лет вызов fsync ()в самой популярной файловой системе Linux мог привести к зависанию всей системы на десятки секунд. Поскольку приложения ничего не могут с этим поделать, очень часто оптимистично использовалось переименование ()без fsync (), что оказалось относительно надежным в этой файловой системе.
Следовательно,существуют приложения, которые неправильно используют fsync ().
В следующей версии этой файловой системы вообще удалось избежать зависания fsync ()-и в то же время начать полагаться на правильное использование fsync ().
Все очень плохо. Пониманию этой истории, вероятно, не помогают пренебрежительный тон и оскорбления, которые использовались многими конфликтующими разработчиками ядра.
Текущее решение состоит в том, что текущая самая популярная файловая система Linux по умолчанию поддерживает шаблон переименования ()без необходимости fsync()реализует «ошибку -для -совместимости ошибок» с предыдущей версией. Это можно отключить с помощью опции монтирования noauto_da_alloc.
Это не полная защита. По сути, он сбрасывает ожидающий ввод-вывод во время переименования (), но не ждет завершения ввода-вывода перед переименованием. Это намного лучше, чем, например. 60-секундное опасное окно! См. также ответ на Какие файловые системы требуют fsync ()для безопасности при сбоях -при замене существующего файла с переименованием ()?
Некоторые менее популярные файловые системы не обеспечивают защиту. XFS отказывается это делать. И UBIFS тоже не реализовал его, по-видимому, его можно было бы принять, но для его реализации требуется много работы. На той же странице указано, что у UBIFS есть несколько других проблем TODO с целостностью данных, в том числе с потерей питания. UBIFS — это файловая система, используемая непосредственно на флэш-накопителе. Я предполагаю, что некоторые трудности, упомянутые UBIFS с флэш-памятью, могут быть связаны с ошибками SSD.