Комментарии 113
Хорошая статья, но эта кроличья нора очень глубока
Могут быть баги в ядре и драйверах, из-за которых данные меняются в процессе записи https://habr.com/ru/articles/263893/
Могуи быть странности изменением данных во время сбороса страниц на диск https://habr.com/ru/articles/219295/comments/#comment_7493865
Даже у HDD сейчас есть свой кэш, который может жить своей жизнью (не говоря уж о SSD)
Нехорошие прошивки контроллеров могут возвращать управление после SYNC, не дожидаясь записи на диск
Прошивки СХД могут вообще игнорировать SYNC, надеясь на батарейную (суперконденсаторную) защиту кэша
И т.д.
Статья плоха даже для журнала "Мурзилка". И это точно не уровень хабра (хотя и по отличным от "Мурзилки" причинам). Хотя… медиахолдинг, говорите? Ну да, ну да...
... могут быть баги в прошивке самого винчестера...
Что произойдёт, если вы отключите компьютер прежде, чем операционная система запишет данные на диск? Всё очень просто: данные будут потеряны.
А как же журналируемые файловые системы?
Так журнал не защищает от потери данных, он защищает от повреждения фс
Журналируемые ФС спасают от повреждения того что уже было записано. Грубо говоря, если нет журнала и свет пропадает во время обновления метаданных ФС, то у вас может посыпаться вся ФС и вы потеряете вообще все. Журнал спасает от этого.
Но если данные никогда не попали из памяти на диск, то чем журнал поможет то?
Журнал нужен для контроля консистентности файловой системы, а не сохранения ваших файлов.
Грубо говоря, если у вас нет журнала, и у вас что-то не так пошло во время записи и вам нужно это исправить (например у вас один блок принадлежит двум файлам, или есть блок который помечен как занят, а на самом деле никем не занят), то раньше для такого выполнялось полное сканирование всех файловых структур, полный обход всего дерева каталогов, что на современных терабайтных дисках займет слишком много времени. Проще заглянуть в журнал, посмотреть незавершенные операции и поудалять их все (недописанные остатки ваших файлов или конфликты), но восстановив целостность файловой системы за секунды.
По умолчанию, да, журналируемая файловая система целостность содержимого обычных файлов от сбоев при их записи не защищает.
Однако журналируемая файловая система может предоставлять сервис, позволяющие приложению сохранять файлы транзакционно, по принципу "все или ничего". Такой сервис, в частности, в Windows предосталяет NTFS, начиная с Vista: TxF,
По поводу TxF - спасибо за упоминание, впервые услышал о таком! Это действительно кроличья нора )
Интересно, но по сути это практически ничего не меняет.
В журнал пишется начало операции, потом в журнале пишется что операция завершена.
Какая именно это была операция - запись файла, удаление, перемещение, компрессия, шифрование, создание снапшота - это уже вторично.
Если операция прервется по какой-либо причине, основной способ все починить - подчистить все шаги незавершенной операции.
del
А давайте вспомним ещё первые Windows и запись на дискету...
Тоже много чудес с потерей данных было из-за кешей...
smartdrv.exe
И (для особых эстетов) с какой скоростью без него ставилась NT 4.0
Ой ... Установка NT запускалась из DOS?
Официально же… беглый гуглеж показывает примерно такое:
Наиболее типичный вариант локальной инсталляции состоит в использовании компакт-диска и трех загрузочных дискет, прилагаемых к дистрибутиву на компакт-диске. Дистрибутив, целиком поставляемый на дискетах 3.5 дюйма, состоит из слишком большого числа дискет и поэтому используется редко.Похоже, что да, своего загрузчика там могло и вообще не быть. Но в точности я не знаю.
Если у вас есть компакт-диск, но нет стартовых загрузочных дискет, то они могут быть получены на начальной стадии инсталляции. Возможен также вариант инсталляции вообще без загрузочных дискет — для этого необходимо стартовать программы winnt.exe или winnt32.exe с ключом /B.
Посмотрел дистрибутив XP - действительно есть winnt.exe и судя по отказу запускаться действительно досовый или по кр. мере 16-битный. Вы правы.
Ну, ХР — это уже чертовски поздняя штука, смартдрайв ей точно не был нужен (а вот насчет 2к, кстати, меня берут некоторые сомнения), и она точно умела грузиться с собственного диска. Хотя могла и пытаться обновлять 9х: скорее всего, winnt.exe там для этого.
Загрузка в XP/2K3 Server (в том числе и при первой инсталляции) была практически без изменений перенесена из исходной версии (с ntldr и boot.ini с его ARC-путями).
Изменение загрузчика произошло при переходе на Vista/2K8 Server.
С 2000, насколько помню, такая же история, как с NT 4 была. Во всяком случае с 4 я дела не имел, а предостережение про смартдрайв в памяти сидит)
Ой ... Установка NT запускалась из DOS?
Установка NT могла запуститься из дос и из виндовс.
Зачем вспоминать? С флешками до сих пор всякая муть творится.
В линуксах да. Отмонтировал флешку и ждешь когда он засинкается. А почему, кстати, нельзя ее монтировать с O_SYNC?
Можно монтировать хоть с sync (будет значительно медленнее работать), хоть с flush (быстрее sync, но медленнее обычного кэширования).
На windows флешки с ntfs тоже будут работать с кэшем и медленно отключаться (или говорить, что устройство занято и пока извлечь нельзя).
Ну вот тут непонятно, зачем на флешке кэш? Мы же там данные приложений не храним, а качаем/заливаем файлы. Почему не делать это напрямую?
все сложнее. одноплатники часто грузятся с флэшек, лайв-образа с persistent storage тоже дело привычное.
Ну вот предположим, что пользователь редактирует документ, расположенный на флешке через обычный MS Word. Редактор при работе создает временный файл в каталоге с документом, и вот вдруг, мы уже там данные приложений храним.
Пользовательский опыт, он такой.
Не сказать что я ими шибко часто пользуюсь, но за 15 лет их использования проблем с ними было пересчитать по пальцам. Во времена XP пару раз SD флешка вайпалась из-за неизвлеченности устройства, но с появлением семёрки у меня только одна бракованная флешка отъехала, остальные пусть медленно, но работали без проблем.
сначала ломанулся проверять не перевод ли это западной статьи, за кордоном столько людей удивляется простым вещам, что я уже перестал давно удивляться. смотрю вроде имя русское, но статья на английском и автор пишет что проживает в Лондоне.
я о кешировании записи узнал в 1992 году на компьютере Искра 1030, чуть позже меня научили писать в NC по F2 команду сброса кеша smartdrv перед выключением ПК. А в нулевых мы вырубали кеш для флешек в Линуксе, ну не нравилось нам сидеть ждать когда данные запишутся после размонтирования тома.
как может человек знать линукс на уровне глубже двойного клика по ярлыку и не знать про кеширование записи?
как может человек знать линукс на уровне глубже двойного клика по ярлыку и не знать про кеширование записи?
Это знание приходит после того, как он в первый раз выдёргивает из компа флешку, на которую скопировал файлик гига где-нибудь на 4 )))
На эту тему есть даже древний анекдот:
Начальник - секретарю:
- Катенька, дорогая, перепиши месячную отчетность нашим партнерам, они сейчас к тебе подойдут.
- Добрый день, это вам переписать oтчетность?
- Добрый день, да, будьте так любезны, вот чистая дискета, можно на нее.
- Да, конечно. Вставляет в дисковод. И....
# mkfs -t vfat -c /dev/fd0h1440
# mount -t vfat -o iocharset=koi8-r,codepage=866 /dev/fd0 /mnt/floppy
# find / -noleaf -type f -name Otchet_april. [a-zA-Z] -exec cp '{ }'; /mnt/floppy \;
# ls -la /mnt/floppy/Otchet_april. [a-z][A-Z] && sync && sleep 3
- Возьмите пожалуйста!
Партнеры. - Них..$%#@я себе!!!
- Что такое?!... Я опять отмонтировать забыла?!
Что такое?!... Я опять отмонтировать забыла?!
Ничего страшного, sync не забыла, так что нормально всё будет ))
Не, просто мы забыли, на дискете была очень важная информация, но вы же только скопировали на дискету, вы ж её не форматировали, хе-хе?
А ещё, кажется, точка с запятой в find лишняя, не? Которая после '{}'.
Хорошо раньше было, когда все флэшки со светодиодами были) Объяснить, что не надо выдёргивать, пока не перестанет моргать, обычно очень просто получалось.
Спасибо за статью. Интересно, отличаются ли подходы записи на диск в разных дистрибутивах?
Учитывая эту трату, мы лучше выполним одну большую операцию записи на 1 мегабайт, чем сто небольших записей по 10 килобайтов каждая.
Я сейчас взорву Вам мозг, но, ВНЕЗАПНО, диск не может записать один байт, он может прочитать 1024 байта (а сейчас — 4096, называется — "сектор", минимально адресуемая единица), изменить в них 1, и записать обратно {{1023|4095} старых + 1 новый}, причём уже при следующем обороте диска, потому что пока читали — сектор уже ушёл из-под головки, и надо ждать, пока он там опять появится.
Обычно размер сектора (блока) все же 512 байт.
На флеш накопителях все еще сложнее, ибо там есть отдельное понятие erase block - минимальный блок который можно стереть. И он может быть вообще недетских размеров - например 256кб. Вот там перезаписать один байт может быть ОЧЕНЬ дорого.
SSD прочитает сектор 4096 байт, запишет его в новый блок и поправит таблицу трансляции.
Когда в старом блоке неиспользуемое место (стирание TRIMом или перезапись) превысит некий процент или SSD будет остро нуждаться в свободном месте для записи (нужны чистые блоки), то остатки информации с блока будут скопированы в новый и блок уйдёт на стирание.
Итого: для SSD записать один байт не дороже HDD.
По времени = чтение+запись сектора.
По ресурсу = чтение+запись сектора.
Нет. Вы просто не сталкивались с ситуацией, когда после некоторого обьема записи данных, скорость SSD резко падает до совсем неприличных значений, и скорость записи SSD становится хуже древних HDD.
Извините, но вы же сами себе противоречите: пишете про то, что требуются операции на работу с таблицой трансляции, и дефрагментации данных пользовательских секторов во внутренних блоках памяти. Но при этом "для SSD записать один байт не дороже HDD"
Обычно размер сектора (блока) все же 512 байт.
Это было ДО 2011 года. Все производители дисков перешли на 4к сектора. В промежуточном варианте могло быть что на уровне железа еще использовались 512-байтные сектора, но контроллер уже оперировал виртуальными 4к секторами.
Ну и уже прошло более 10 лет. ВСЕ HDD уже нативно 4к.
Флеш не знаю, там могут быть эксперименты, но я уверен что только в бОльшую сторону
и да "сектора (блока)" - не путайте блок и сектор. Блок или кластер - это уровень файловой системы. Сектор - низкоуровневый, туда уже не лазят с тех пор как контроллер переехал с материнки в диск.
Если вы купите сейчас диск и спросите его о геометрии — то в большинстве случаев вам скажут что-то подобное. И не важно, кто там производитель.
"Sector size (logical/physical): 512B/512B"
Впрочем, ничего не скажу по SMR дискам — предпочитаю стандартные.
Парочка аргументов.
Переход из 512байтных секторов в 4кбайтные сектора позволяют сэкономить примерно 10% дискового пространство только на служебных данных.
То есть ты просто ничего не делаешь, не упихиваешь плотность магнитной записи, не калибруешь головки чтобы впихнуть еще одну дорожку, просто правишь в прошивке немного софта и получаешь +10% объема на том же диске.
И вы хотите сказать есть еще производители, которые готовы сказать что их диск меньше чем у конкурентов?Терабайтные диски это больше чем гигабайтные. В среднем размер одного файла давно вырос до того, чтобы оперировать 4кбайтными блоками было выгоднее, чем 512байтными - это вообще еще в 90е исследования вели. Подавляющее большинство файловых систем давно могло использовать 4к блоки по дефолту, разве что ты специально установишь другой размер. Вдобавок 4к это размер страницы памяти.
Иметь сектор и кластер разного размера - проблемы с перформансом, а рейтинги дисков со статистикой очень быстро публикуются различными блоггерами. Поэтому сейчас просто глупо не поддерживать AF под дефолтуПрям даже не знаю каким образом вы спрашиваете диск о "Геометрии". Геометрия это IMHO в первую очередь CHS. Возможно вы проверили какой-то древний диск до 2011 года выпуска или проверяли это из старой ОС. Там были варианты которые могли внутри уже быть 4к, а контроллер наружу отдавал 512b для совместимости с WinXP и более старыми ОС.
AF подерживается начиная с Windows Vista.
В современных дисках можно смело читать датащит любого производителя. А некоторые все еще могут прямо писать AF или 4k native на наклейке.
Advanced Format
Кстати в те же времена (в районе 2010-2012 годов) практически у каждого производителя была доступна утилитка типа align (wd_align) и так далее. Вся задача которой была выровнять первый кластер загрузочного диска в соответствии с сектором. Потому что XP, не зная про AF, по дефолту могла создать раздел, начиная его не с кратного сектора. В результате при любом считывании/записи блока, контроллер диска сильно страдал - ему надо было считать два сектора/записать два сектора. Перформанс дико падал.
Можете навскидку привести хотя бы парочку устройств, выпущенных за последние лет 5, где сектор 512б? Хотел бы убедиться что такое еще существует на массовом рынке.
>Можете навскидку привести хотя бы парочку устройств, выпущенных за
последние лет 5, где сектор 512б? Хотел бы убедиться что такое еще
существует на массовом рынке.
Начал шариться по первым попавшимся серверам, HDD-диски да 512/4096
Но вот есть SSD 512/512 почему и зачем?
Hidden text
=== START OF INFORMATION SECTION ===
Device Model: SAMSUNG MZ7WD480HMHP-00003
Firmware Version: DXV8003Q
User Capacity: 480 103 981 056 bytes [480 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
TRIM Command: Available, deterministic, zeroed
это китайская подделка
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 860 EVO 500GB
Serial Number: 2022102100219
Firmware Version: U0625A0
User Capacity: 500 107 862 016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
TRIM Command: Available
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 T13/2015-D revision 3
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat Jul 29 01:19:29 2023 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
это оригинал
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 870 QVO 4TB
Serial Number: S5STNF0T205912B
LU WWN Device Id: 5 002538 f4221d451
Firmware Version: SVQ02B6Q
User Capacity: 4 000 787 030 016 bytes [4,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat Jul 29 01:20:31 2023 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
в SSD нет секторов как в hdd.
Ибо нет намагниченных областей, для которых нужна разметка, gap, crc области.
Такие вещи, как размер сектора и вообще смысл перехода с 512б на 4к формат в принципе нельзя применять к SSD накопителям, которые дискретны изначально.
В SSD Есть микросхемы памяти, есть контроллеры этих микросхем. и SSD не может считать байт или кусок микросхемы, он читается целиком. Я сомневаюсь что минимальный размер физического чипа памяти там такой маленький. В современных условиях проще штамповать микросхемы наверное по мегабайту хотя бы, а наружу проецировать логические 512б для совместимости, ибо на перформансе это не сильно отражается. наверное.
Но про потроха SSD я не готов говорить. Главное - Advanced Format не применим к SSD, там вообще смотреть на факторы влияющие на перформанс надо с другой позиции.
Хм, согласен, parted врёт. Если спросить smartctl, то система говорит про них "Sector Sizes: 512 bytes logical, 4096 bytes physical". И в описании пишут, что они 512e.
WD6003FRYZ-01F0D, WD40PURZ, st12000nm001g-2mv103
WD6003FRYZ - точно 512e (то есть физически 4к, логически поддерживается 512б для совместимости)
WD40PURZ (отсюда взял https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-purple-hdd/product-brief-wd-purple-hdd.pdf)
Все Purple поддерживают Advanced Format (AF)
st12000nm001g aka Seagate Enterprise ST12000NM001G:
Cache 256 MB, Standard Model FastFormat™ (512e/4Kn), 20 Pack, то есть логический 512, нативный 4k (https://icecat.biz/en-sa/p/seagate/st12000nm001g-20pk/enterprise-internal+hard+drives-st12000nm001g-79545808.html)
Эта совместимость лет 10-15 назад была важна для Windows Server (как сейчас — не в курсе). Потому что движок ESE (транзакционный NoSQL движок БД от MS, сначала он был чисто внутренним, потом его сделали публичным) довольно долго не умел поддерживать сектора размером кроме 512 байт (потому что он старый, делался где-то в середине 90-х), а на этом движке были реализованы многие внутренние БД Windows Server (например, база AD), а также MS Exchange.
Так что мне чисто по работе приходилось тогда следить, какие диски закупаются и как конфигурируются.
Мне кажется, что движок, который поддерживает СЕКТОРА (а не кластера), не имеет право на существование со времен NTFS.
Опять таки, для разделов больше десятка гигабайт, кластер размером 512байт уже не выгоден.
Вам может казаться что угодно, но такой движок существовал и даже приносил MS деньги.
А необходимость поддержки именно сектора в ESE возникла из-за требования синхронной записи на диск для журнала транзакций (разумное требование, не так ли?).
Другими словами, такой движок обязан работать с правами администратора в обход стандартных функций операции записи/чтения.
Нет. Можно использовать обычную запись, выравненную по границе сектора и длинной данных в размер сектора.
А как вы достучитесь до сектора, если вы не имеете права напрямую работать с контроллером устройства, если ваш процесс не запущен с привилегиями?
Записать в файл данные размером с сектор по смещению, выравненному на границу сектора. Эти данные неизбежно попадут в один сектор. Если файл открыт для записи без буферизации в ОС, напрямую на диск (с FILE_FLAG_NO_BUFFERING), то выравнивать смещение на границу сектора — это требование к операциям чтения/записи таких файлов (а требование к размеру данных — должен быть кратным размеру сектора).
Ну это же не работа с секторами. Тут даже не очень понятно в чем выигрыш и насколько он заметен.
Насчет совместимости - если под капотом 4к сектор, а windows думает что 512б, то перформанс прям таки не светит.
Ну это же не работа с секторами.
Так я и не писал, что движок ESE работает именно с сектрами напрямую. Он, скорее всего (в документации по ESE я этого не видел, сужу по тому, что позволяет Win32 API), работает через обычный (почти: небуферизованный) файловый ввод/вывод, но — с учетом размера сектора: собственно, API заставляет его так работать.
Тут даже не очень понятно в чем выигрыш и насколько он заметен
В надежности записи: если файл открыт как небуферизованный и со сквозной записью (есть такой флаг в CreateFile), то возврат из операции записи происходит только после того, как содержимое записано в надежное место — на диск (или в кэш СХД со своим UPS).
Насчет совместимости — если под капотом 4к сектор, а windows думает что 512б, то перформанс прям таки не светит.Так пишется журнал транзакций, запись в него — последовательная, так что потери скорости записи должны быть невелики.
По факту это работа хоть и на высоком уровне, но сектора записываются каждый целиком
А какой взрыв мозга начинается, если задуматься над тем, а что будет если выключить электричество именно в момент перезаписи физического сектора на диске.
А если это SSD, у которого размер сектора на самом деле не 512 и не 4096 байт...
Энергии в конденсаторах хватит для завершения операции.
А он не перезаписывает сектор, он его переносит в свободный с модификацией нужной части. После завершения - пометит старый, как подлежащий стиранию. Это нужно для выравнивания износа, иначе он в часто используемых местах дырку протрет. Соответственно более менее сносно всё. Но вот алгоритмы работы с флешем у всех производителей свои, и кеши сейчас объёмные, поэтому это тёмный лес, конечно...
А какой взрыв мозга начинается, если задуматься над тем, а что будет если выключить электричество именно в момент перезаписи физического сектора на диске.
Подождите. А что делать с необходимостью экстренно парковать головки чтения-записи, при резком обрубании электричества. Раньше писали, что... Я уже и забыл, что именно. Короче! При штатном отключении головки паркуются куда надо. А что происходит при аварийном отключении? Даже и знать не хочется... :-(
При штатном отключении головки паркуются куда надо. А что происходит при аварийном отключении?Тоже самое, ЕМНИП. У них хватает заряда припарковаться.
что будет если выключить электричество именно в момент перезаписи физического сектора на диске.
Ничего не будет. В разъёме ATX есть линия PWR_OK ("питание в порядке"). В нормальном рабочем состоянии на нём высокий уровень. При пропадании напряжения в сети уровень переключается на низкий, и все устройства получают команду "мы падаем, всем приготовиться". Винчестеры аварийно сбрасывают свои внутренние кэши на диск — энергии, запасённой коденсаторами блока питания, на это хватает. В крайнем случае у винчестера в расоряжении есть ещё и энергия вращающихся пластин — мотор шпинделя переходит в режим генератора. Когда дело сделано, отключаются электромагниты привода головок, и они под действием пружины сами отходят в парковочную позицию. Так что "партия всё предусмотрела, товарищи, вы полетите ночью" (c).
Спасибо, не знал, что всё настолько круто.
не знал
"Так ведь, Петька, я и постарше тебя буду-то..." (c)
Это все городские легенды. (с)
1) команду "мы падаем, всем приготовиться"
а можно ссылочку на такую команду, что она успевает передаться? Совершенно непонятно, кто успевает ее отправить и каким образом.
Я не спорю есть штатная команда, которая отправляется перед штатным выключением, но не в данном случае.
2) Винчестеры аварийно сбрасывают свои внутренние кэши на диск — энергии, запасённой коденсаторами блока питания, на это хватает.
Простите чьего блока питания? Китайского БП на 300 китайских ватт с высохшими конденсаторами? Внутри HDD блок питания условный, там просто стабилизаторы напряжения для рабочих напряжений электроники.
4) сбрасывают свои внутренние кэши на диск
кэши дисками не записываются при потере питания. Вам об этом даже в статье написали. Если хотите надежно записать данные на физический носитель, используйте при записи флаг SYNC, тогда данные сразу попадут на физическую ячейку памяти носителя.
Но некоторые носители при определенных условиях могут игнорировать этот флаг, и сразу рапортовать о том, что записали. Например, так делают SSD c конденсаторами. НО не все SSD имеют конденсаторы, и некоторые SSD без конденсаторов ведут себя, как будто имеют резервный запас энергии, те банально обманывают систему, и в случае сбоя потеряют данные.
Другой пример, есть RAID контроллеры с батарейкой. Некоторые думают, что это батарейка, для того чтобы диски успели записать данные. Так вот НЕТ. Эта батарейка для питания чипов памяти кэша контроллера. Данные из кеша будут записаны при следующем включении. И если питание не вернется через N-часов, то данные в кеше будут потеряны.
И вот кстати, именно RAID контроллеры с батарейкой при настройках по умолчании игнорируют флаг SYNC предполагая, что батарея заряжена и работает штатно. Пока внезапно не выяснится, что самопроверка контроллера не выявила, что батарея не сохраняет заявленное количество энергии.
5) мотор шпинделя переходит в режим генератора
а можно ссылочку? имхо городская легенда. Если мотор переключить в режим генератора, диски еще быстрее остановятся, а у нас как бы обратная задача - успеть записать данные в режиме, когда скорость дисков уже невозможно поддерживать в штатных пределах.
Из практики при выключении диска в момент записи, сектор успевается пометится как сбойный и увеличивается счетчик Current Pending Sector Count. При следующем чтении этого сектора, если все ок, то сектор возвращается в работу, а счетчик Pending уменьшается.
а можно ссылочку на такую команду, что она успевает передаться?
А в чём проблема-то? На всё про всё есть ещё примерно 0,1 секунды — это при 5400 RPM — порядка 90 оборотов шпинделя.
кто успевает ее отправить и каким образом.
Гуглите PWR_OK, и будет вам ЩАСТЬЕ. Сказано ж — это отдельная линия в ATX разъёме. Уровень меняется с высокого на низкий — матплата приступает к тушению света.
Китайского БП на 300 китайских ватт с высохшими конденсаторами?
С китайского БП все взятки гладки — скажет "ну не шмогла я".
кэши дисками не записываются при потере питания.
Кэши ОС, естественно, не записываются. Внутренние кэши драйва — те, которые расположенвы на плате самого винчестера — насколько мне известно, таки записываются (естественно, если в момент потери питания шла активная запись — в противном случае и записывать-то, собственно, ничего не надо.)
как бы обратная задача - успеть записать данные в режиме, когда скорость дисков уже невозможно поддерживать в штатных пределах.
А какая разница, штатные там пределы или не штатные? Тут уже аварийная ситуация, поддержание обещанной спецификацией скорости обмена уже никого не волнует. А синхрометки с дисков никуда ведь не делись.
Я в курсе про PWR_OK. Насколько я помню, этот сигнал использовался для проверки готовности к старте системы, и если его коротнуть на землю, то система мгновенна уходила в ребут.
Hidden text
В интернете кто-то не прав.
Давайте зафиксируем предмет спора.
Те вы утверждаете, что при потере сигнала PWR_OK материнская плата каким-то образом передает сигнал по какой-то шине подключенным устройствам, что-то вроде "я потеряла питание, вы там как-нибудь сами".
>Внутренние кэши драйва — те, которые расположенвы на плате самого винчестера — насколько мне известно, таки записываются
насколько мне известно, НЕ записываются. Особенно если это обычные потребительские диски, а не диски уровня enterprise.
Смотрите, какой потрясающий пример.
SSD теряет данные из кэша при потере питания. И это не баг в прошивке, как может показаться на первый взгляд.
This firmware will change the default write cache setting from enable to
disable on the 50 GB 1.8-inch SATA Non Hot-Swap Solid State Drive.
В следующей версии просто по умолчанию будет отключен кеш. и все. И нет никаких конденсаторов.
винчестера
SSD теряет данные
Вы совсем-совсем никаких несоответствий тут не видите? Точно?
>А какая разница, штатные там пределы или не штатные? Тут уже аварийная ситуация, поддержание обещанной спецификацией скорости обмена уже никого не волнует. А синхрометки с дисков никуда ведь не делись.
Действительно никакой разницы, что головки и управляющий софт, рассчитаны читать и записывать на штатной скорости в определенных отклонениях.
И теперь вы предлагаете "заинженерить некий алгоритм дозаписи данных" в аварийной ситуации?
А вам инженеры ответят. Если хотите надежно писать, используйте флаг FUA. Наша задача обеспечить безопасность поверхности диска и головок в аварийной ситуации, а не безопасность ваших данных.
FUA When set to one forces the data to be written to the storage media before completion status is indicated. When cleared to zero the device may indicate completion status before the data is committed to the media.
https://sata-io.org/system/files/specifications/SerialATA_Revision_3_1_Gold.pdf
Другой пример, есть RAID контроллеры с батарейкой. Некоторые думают, что это батарейка, для того чтобы диски успели записать данные. Так вот НЕТ. Эта батарейка для питания чипов памяти кэша контроллера. Данные из кеша будут записаны при следующем включении. И если питание не вернется через N-часов, то данные в кеше будут потеряны.
Чаще это батарейка для записи DRAM кэша во встроенный флэш. Да и ту уже чаще заменяют на ионистор, которого на запись точно хватает. Так что современный контроллер нормального производителя ничего не потеряет даже при долгом отсутствии питания.
Совершенно непонятно, кто успевает ее отправить и каким образом.
Проблема парковки головок сейчас отсутствует. Все производители HDD масс сегмента выпускают диски, которые могут нормально запарковаться в случае потери питания.
Сохранить данные - тут уже вряд ли. В любом случае внутренняя память в дисках чаще служит для ускорения чтения, чем записи, и для записи обычно используется очень и очень кратковременно, на уровне расчета траектории перемещения головок, чтобы использовать параллельную запись, если такое есть
Другой пример, есть RAID контроллеры с батарейкой. Некоторые думают, что это батарейка, для того чтобы диски успели записать данные. Так вот НЕТ. Эта батарейка для питания чипов памяти кэша контроллера. Данные из кеша будут записаны при следующем включении. И если питание не вернется через N-часов, то данные в кеше будут потеряны.
Бывает ещё "хуже", когда батарейка используется для сброса кешей на специальный выделенный SSD-диск, с которого при включении восстанавливается содержание кеш-памяти для последующего сброса на диски.
Когда деревья были большими, такого не было и наблюдать пропилы от головок на пластинах при аварийном отключении приходилось. Правда и диски тогда были с обьёмами по 40 мегабайт :)
Головки дисков просто падали на пластины, туда, где их застало отключение энергии. На диске появлялись порченные сектора. Сектор за сектором.
происходит то же самое. Головки паркуются за счет кинетической энергии вращающихся дисков. То есть, мотор в HDD на долю секунды работает как генератор и посылает на привод головок импульс для парковки
он может прочитать 1024 байта, изменить в них 1, и записать обратно
С черепичной записью так уже нельзя
Кроличья нора углубляется.
Удивитесь ли вы, если я скажу, что запись 1 байта вызывает запись на диск 65 тысяч байтов?
Нет, мы знаем про сектора. Еще вирусы под DOS умели себя в последнем секторе файла прятать, чему тут удивляться?
Главное, что я извлек из этой статьи: у автора, похоже, эпилепсия. Поскольку его постоянно трясет, с каждой новой страницей книги "Linux для полных дебилов".
Удивитесь ли вы, если я скажу, что запись 1 байта вызывает запись на диск 65 тысяч байтов?
Сильно удивлюсь.
Ибо современный размер сектора - 4 кб, и в нормальной ситуации, запись выполняется по секторам.
Может быть, из-за того, что у вас было несколько операций записи, которые закешировались на уровне ОС или контроллера диска, и очередная запись 1 байта наконец повлекла запись всей цепочки, но это вы тогда хитрите.
Если же у вас запись 1 байта на диск провоцирует запись 64к байт, что-то пошло не так. Или кто-то экспериментирует с ssd/флеш дисками - там под капотом могут быть нюансы.
P.S. Честно говоря, статья разочаровала. О банальных и давно известных вещах пишется во-первых с большим удивлением, во вторых с кучей неточностей и некорректностей, из-за чего новичок только запутается.
Тот же "файл это интерфейс" - нет, интерфейс это интерфейс, например handler это интерфейс.
А файл и директория - это термины, которые обозначают определенные сущности на хранителе информации. Та же iNode это тоже не интерфейс, а способ организации posix файловой системы. В других файловых системах могут быть другие способы, FAT, MFT..
Ибо современный размер сектора - 4 кб
Размер кластера в ФС тоже 4 килобайта по умолчанию. Но я, например в последнее время ставлю 64к, потому что на дисках в основном большие файлы. Вот тебе и запись минимум 64к )) . На одном диске вообще два мегабайта размер кластера. Там совсем большие файлы
Кластер – это всего лишь единица распределения дискового пространства. Он не обязан записываться целиком.
Так больший размер сектора просто расширяет максимальное количество индексируемых данных. Ну и журнал вроде может поменьше сделать.
ну в вашем случае вы же не удивляетесь, вы же специально такой размер выбрали.
Но насчет больших файлов - вопрос не в размере файла, а в размере операций записи/чтения. Если в этих файлах (например это базы данных) делаются мелкие изменения, то перфоманс вы себе таким образом ухудшили =)
А вот при линейном копировании/чтении (например онлайн кинотеатр, где нужно тупо линейно читать и писать большие объемы данных) - там большой размер кластера прямая выгода.
На примере FAT. Возможно имеется в виду не только дописать байт в конец, но так же и изменить размер файла в таблице, время последнего доступа и изменения, возможно добавить новый кластер в обе копии FAT, изменить количество свободного места на диске.
начало вроде для совсем начинающих а потом бац, O_SYNC и sync, термины, и открываем файл уже как лютые программисты.
Насколько медленные? Получение небольшой порции данных с SSD в тысячу раз медленнее, чем получение её из памяти.
прям в тысячу ? можно конкретные цифры ?
смотрю википедию:
Для памяти с эффективной частотой 3200 МГц (наибольшая частота,
изначально определённая стандартом) максимальная пропускная способность
составит 3200 × 8 = 25 600 МБ/c
https://ru.wikipedia.org/wiki/DDR4_SDRAM
Например, скорость диска Samsung 970 EVO Plus MZ-V7S250BW 250ГБ, M.2
2280, PCI-E x4, NVMe (на картинке выше) на чтение – 3500 МБ/с, а на
запись — 2300 МБ/с.
https://selectel.ru/blog/ssd-m2-nvme/
Это автор вообще не пытался работать с SSD и памятью. Кроме памяти есть еще пропускная способность шины, а там может выясниться что все совсем уже и не так радужно.
Вдобавок, если брать не просто работу с памятью, а работу с каким-нить рамдиском, то его производительность вполне сопоставима с PCI-E NVMe, причем настолько сопоставима, что я отказался от использования рамдисков еще лет 5 назад.
Вдобавок, если брать не просто работу с памятью, а работу с каким-нить рамдиском, то его производительность вполне сопоставима с PCI-E NVMe
Возможно, если воткнуть nvme в слот, который находится "близко" к процессору, то скорость будет как-то сопоставима, но на чисто эмоциональном уровне я не верю )))
К тому же tmpfs не использует кеш о котором столько сказано в тексте статьи, а значит в должна быть побыстрее хотя бы формально.
И наконец, интесивная работа в tmpfs не истощает ресурс ssd ))
Хотя, конечно, было бы неплохо проверить, какая там разница по скорости будет, я только не уверен как это сделать. Могу ядро скомпилировать, но не уверен, что это показательно
А что, к Windows и другим ОС всё перечисленное не относится? Так с дисками только Linux работает?
Относится — просто от Windows никто великих свершений и не ожидает :)
Ну, или все знают, что Windows просто работает, а как именно — это вам знать не обязательно :-)
Спасибо. Наконец-то я понял что такое inode, зачем буфер нужен и многое другое. Вот что значит простым языком и примерами объяснить сложные вещи. А то сколько ни читал книжки и всякие статьи - всё заумным языком объясняется.
вы поняли неправильно. Автор сам неглубоко вник в суть вопроса, и что такое iNode пояснил некорректно.
iNode это просто метаинформация о записи в файловой системе, которая относится к конкретному файлу/директории или другой сущности файловой системы.
В винде для таких целей есть тот же MFS и directory entry там содержит больше данных. в FAT использовались directory entry и file allocation table.
Это просто потроха файловых систем, где хранятся данные о структуре и различных аттрибутах.
В любом линуксе пиши
stat <path>
и тебе выдаст почти все что находится в конкретной iNode
В винде для таких целей есть тот же MFS и directory entry
В NTFS аналогом iNode является запись в MFT (Master File Table, полагаю, что у вас тут просто была описка). В элементе же каталога (directory entry) содержится ссылка на эту запись MFT для файла: в NTFS может быть несколько ссылок на один файл (то, что в Unix называется hardlink) по разным путям. В FAT ссылка всегда только одна, по единственному пути, информация о файле, включая первый назначенный ему кластер, содержится именно в элементе каталога по пути файла, а в FAT — односвязный список кластеров, назначенных файлу.
iNode это просто метаинформация о записи в файловой системе
Чтоб далеко не ходить
struct inode {
struct hlist_node i_hash; /* hash list */
struct list_head i_list; /* list of inodes */
struct list_head i_dentry; /* list of dentries */
unsigned long i_ino; /* inode number */
atomic_t i_count; /* reference counter */
umode_t i_mode; /* access permissions */
unsigned int i_nlink; /* number of hard links */
uid_t i_uid; /* user id of owner */
gid_t i_gid; /* group id of owner */
kdev_t i_rdev; /* real device node */
loff_t i_size; /* file size in bytes */
struct timespec i_atime; /* last access time */
struct timespec i_mtime; /* last modify time */
struct timespec i_ctime; /* last change time */
unsigned int i_blkbits; /* block size in bits */
unsigned long i_blksize; /* block size in bytes */
unsigned long i_version; /* version number */
unsigned long i_blocks; /* file size in blocks */
unsigned short i_bytes; /* bytes consumed */
spinlock_t i_lock; /* spinlock */
struct rw_semaphore i_alloc_sem; /* nests inside of i_sem */
struct semaphore i_sem; /* inode semaphore */
struct inode_operations *i_op; /* inode ops table */
struct file_operations *i_fop; /* default inode ops */
struct super_block *i_sb; /* associated superblock */
struct file_lock *i_flock; /* file lock list */
struct address_space *i_mapping; /* associated mapping */
struct address_space i_data; /* mapping for device */
struct dquot *i_dquot[MAXQUOTAS]; /* disk quotas for inode */
struct list_head i_devices; /* list of block devices */
struct pipe_inode_info *i_pipe; /* pipe information */
struct block_device *i_bdev; /* block device driver */
unsigned long i_dnotify_mask; /* directory notify mask */
struct dnotify_struct *i_dnotify; /* dnotify */
unsigned long i_state; /* state flags */
unsigned long dirtied_when; /* first dirtying time */
unsigned int i_flags; /* filesystem flags */
unsigned char i_sock; /* is this a socket? */
atomic_t i_writecount; /* count of writers */
void *i_security; /* security module */
__u32 i_generation; /* inode version number */
union {
void *generic_ip; /* filesystem-specific info */
} u;
};
Конкретный способ упорядочивания байтов на диске называется inode.
Ну это уже просто ни в какие ворота. inode к диску никакого отношения не имеют, они существуют только на уровне файловой системы. А Линукс может прекрасно работать с не-юниксовыми файловыми системами, где инодов может и вообще не быть. В общем, читайте книжки, учитесь.
Алина Маратовна, занимайтесь лучше гимнастикой, устройство операционных систем — явно не та тема, в которой вы хоть что-то понимаете и способны это стройно изложить.
Как на самом деле Linux выполняет запись на диск?