Друзья мои, программисты и операторы, я бы хотел поговорить о том, как в Linux работает запись файлов.
Раньше я думал, что она устроена определённым образом, и как Джон Леннон, «I’m not the only one». Оказалось, операции записи работают совершенно иначе. То, как они работают, интересно и важно знать.
Позвольте начать с того, как я раньше думал о записи файлов.
вы вводите команду
echo "foo" > bar.txt(спустя несколько микросекунд) бум, всё готово, строка «foo» записана на диск.
Я думал так, потому что считал, что файлы находятся на диске, поэтому если выполняется запись в файл, то она выполняется на диск.
Но это так не работает, и описанная выше модель о нахождении файлов на диске ошибочна.
Давайте начнём с демонстрации того, почему ошибочна эта модель.
Файлы не находятся на диске
Логично думать, что файлы находятся на диске, потому что файлы — это то, с чем мы взаимодействуем при записи данных на диск.
Но дело в том, что на самом деле файл — это интерфейс. Операционная система использует этот интерфейс, чтобы мы могли сказать ей, чего хотим.
Пока всё это немного теория, поэтому позвольте повторить: файлы — это интерфейс, во многом похожий на экземпляр ООП с методами и атрибутами. Файлы — это не единицы на диске. Это всего лишь абстрактный интерфейс для них.
Но что же тогда находится на диске? Байты.
На диске находятся байты
Диск — это просто мешок с байтами. Разумеется, эти байты имеют структуру. В противном случае они были бы произвольными, и мы бы не смогли извлечь из них пользу. Конкретный способ упорядочивания байтов на диске называется inode. inode — это то, что в конечном итоге описывается при помощи файла.
Можно сравнить inode с jpeg: это способ упорядочивания байтов определённым образом. Например, inode указывает, что в определённом месте вашего мешка с байтами записывается размер файла. В другое место записывается время создания файла.
Но почему бы тогда просто не взаимодействовать с inode?
Зачем использовать интерфейсы
Напрямую выполнять запись на диск можно. Нужно точно знать, куда выполнять запись, и необходимо записывать эти байты напрямую. Вероятность ошибок крайне высока.
Поэтому гораздо удобнее просто попросить об этом операционную систему. Благодаря этому мы можем сосредоточиться на собственных приложениях.
И это одна из причин использования интерфейсов: мы абстрагируем задачи, которыми не хотим заниматься.
Ещё одна важная причина — это эффективность. Делегируя доступ к диску операционной системе, мы даём программистам операционной системы разрешение принимать множество эффективных решений.
Диски медленные
Давайте вернёмся к нашей гипотезе:
вы вводите команду
echo "foo" > bar.txt(спустя несколько микросекунд) бум, всё готово, строка «foo» записана на диск.
Она абсолютно ложна. Если бы она была верна, компьютеры бы казались ужасно медленными. Диски о-о-очень медленные.
Насколько медленные? Получение небольшой порции данных с SSD в тысячу раз медленнее, чем получение её из памяти. Получение тех же данных с жёсткого диска в миллион раз медленнее. Дисковый доступ на много порядков медленнее, чем доступ к памяти!
Вспомним, что до SSD диски были последними механическими элементами компьютеров (если не считать вентиляторов). В мире скоростного перемещения электронов мы перемещали атомы. Это различие в скорости между электрическим и механическим миром огромно.
Поэтому операционные системы делают всё возможное, чтобы защитить приложения от этой медленности.
Как они это делают?
Как на самом деле работает запись?
Вот, как работает запись.
вы вводите команду
echo "foo" > bar.txtоперационная система копирует «foo» в особое место памяти под названием страничный кэш
(несколько микросекунд спустя) операционная система сообщает, что запись успешно выполнена
(асинхронно, спустя до тридцати секунд) операционная система на самом деле записывает «foo» на диск
Если вы привыкли к мысленной модели «файлы находятся на диске», то это вас потрясёт. Лично я привык считать, что запись на диск происходит мгновенно, но на самом деле она выполняется спустя тридцать секунд!
Зачем нужна такая асинхронность?
Допустим, вы сделали приложение для публикации фотографий с кнопками Like. Лайки под фото сохраняются в базе данных. Однако если бы вы лично проектировали это приложение, то предпочли бы…
Чтобы сердечко лайка появлялось как только пользователь нажмёт на кнопку Like?
Чтобы сердечко появлялось только после того, как лайк был сохранён на диск?
Разумеется, вы выбрали бы вариант 1, потому что отзывчивость UI очень важна.
Это пример защиты пользователя от медленной работы при помощи асинхронности: мы сообщаете пользователю, что сделали это, но на самом деле, делаете это позже, когда он не смотрит.
С Linux ситуация почти такая же. Он защищает приложение от медленности диска, просто выполняя запись на диск позже. Это называется неблокирующим вводом-выводом: мы не заставляем приложение ждать медленные диски.
Однако это не единственная причина асинхронности записи.
Буферизация также ускоряет запись на диск
Важно уяснить следующее: асинхронность позволяет использовать буферизацию.
Позже я исследую эту тему глубже, а пока скажу, что меня потрясло то, насколько часто встречаются буферы и очереди в computer science. Не сказать, что это какой-то секрет, но они важнее для эффективных вычислений, чем я думал.
Очереди и буферы также повышают эффективность записи на диск.
Например, каждая запись на диск связана с тратой дополнительных ресурсов. Учитывая эту трату, мы лучше выполним одну большую операцию записи на 1 мегабайт, чем сто небольших записей по 10 килобайтов каждая. Буферизация записей на диск позволяет операционной системе объединять эти небольшие записи в более крупные.
Так как операционная система отделяет запись в файл от настоящей записи на диск, то если вы быстро выполняете серию записей файлов, то они объединятся в небольшую очередь. Затем операционная система может их объединить.
На самом деле, существует гораздо больше трюков, позволяющих повысить скорость записей, и все они становятся возможными благодаря этой асинхронности. Возможно, я расскажу о них в другой статье, но если вам не терпится, крайне рекомендую прочитать главы «File System» и «Disk» книги Брендана Грегга «Systems Performance».
Как бы то ни было, мы теперь понимаем, что асинхронные записи на диск дают нам огромный рост скорости, но здесь есть ещё один аспект: какой же ценой?
Компромисс между эффективностью и надёжностью
Что произойдёт, если вы отключите компьютер прежде, чем операционная система запишет данные на диск? Всё очень просто: данные будут потеряны.
Мне бы хотелось найти обсуждение, в котором намеренно было принято это решение, но у такого варианта как будто и не было альтернатив: до недавнего времени запись на диск была в миллион раз медленнее, чем доступ к памяти. Разумеется, по умолчанию запись выполнялась асинхронно.
Но что, если мы хотим сделать наши операции записи надёжными?
O_SYNC и sync: делаем записи надёжными
Хотя лично меня удивил факт асинхронности записей, многие программисты, и, в частности, программисты баз данных, хорошо о нём знают.
Существует множество способов сделать записи надёжными. Я расскажу о двух из них.
Системный вызов sync
Существует системный вызов под названием sync, который можно совершить в любой момент. Он означает «операционная система, немедленно сбрось всё из страничного кэша на диск!» И операционная система сделает это. Вы даже можете прямо сейчас ввести эту команду в шелл, чтобы проверить.
В программах часто встречаются последовательности записей, перемежаемые вызовами sync. Например, через каждые n записей выполняется вызов sync. Это позволяет приложениям тонко настраивать баланс между надёжностью и скоростью записи.
Файловый режим O_SYNC
Также программисты могут открывать файл в режиме O_SYNC. Это действие гораздо ближе к модели, изложенной в начале статьи: запись завершается только тогда, когда данные были сохранены на диск.
Демонстрация асинхронных записей
Настало время для научной демонстрации. Я буду выполнять запись в файл и чтение из файла. При этом я покажу, что обе операции выполнятся за секунды до того, как будет выполнен доступ к диску.
В шелл я вставлю следующие команды:
echo "foo" > example.txt
dd if=example.txtНиже показан результат выполнения bpftrace, позволяющей отслеживать события ядра.
В частности, мы будем отслеживать моменты завершения vfs_read и vfs_write (вам достаточно знать, что это функции, вызываемые при чтении и записи в файл). Также мы будем отслеживать block_rq_issue, которая вызывается, когда драйвер диска на самом деле выполняет запись на диск.
# запись начинается
11:32:05 kfunc:vmlinux:vfs_write
запись заканчивается
11:32:05 kretfunc:vmlinux:vfs_write
считывание начинается
11:32:05 kfunc:vmlinux:vfs_read
считывание заканчивается
11:32:05 kretfunc:vmlinux:vfs_read
5 секунд спустя действительная запись "foo" на диск!
11:32:10 tracepoint:block:block_rq_issueОбратите внимание, что мы даже никогда не считываем с диска, хотя и считываем файл. Так происходит, потому что чтение выполняется из страничного кэша!
Особенность: это поведение не универсально
Использование или неиспользование страничного кэша для считывания и записи на самом деле зависит от файловой системы. Однако самые распространённые файловые системы Linux (ext4, btrfs, XFS) используют страничный кэш. С ZFS ситуация чуть сложнее. Хотя в ней используется страничный кэш, у неё также есть собственный относительно сложный механизм кэширования.
Заключение
Надеюсь, это помогло вам привести свою мысленную модель в соответствие с реальностью. На диске находятся не файлы, а байты. Файлы просто описывают эти байты. Это расхождение упрощает программирование и позволяет операционной системе защитить наши быстрые приложения от медленных дисков.
Эта тема гораздо шире — разница между файловым и дисковым вводом-выводом намного глубже. Например, какой объём будет записан на диск при записи 1 байта в файл? Удивитесь ли вы, если я скажу, что запись 1 байта вызывает запись на диск 65 тысяч байтов? И существует ещё множество таких тонкостей.
Комментарии (93)
igorzakhar
27.07.2023 12:50+2Что произойдёт, если вы отключите компьютер прежде, чем операционная система запишет данные на диск? Всё очень просто: данные будут потеряны.
А как же журналируемые файловые системы?
lorc
27.07.2023 12:50+7Журналируемые ФС спасают от повреждения того что уже было записано. Грубо говоря, если нет журнала и свет пропадает во время обновления метаданных ФС, то у вас может посыпаться вся ФС и вы потеряете вообще все. Журнал спасает от этого.
Но если данные никогда не попали из памяти на диск, то чем журнал поможет то?
saboteur_kiev
27.07.2023 12:50+2Журнал нужен для контроля консистентности файловой системы, а не сохранения ваших файлов.
Грубо говоря, если у вас нет журнала, и у вас что-то не так пошло во время записи и вам нужно это исправить (например у вас один блок принадлежит двум файлам, или есть блок который помечен как занят, а на самом деле никем не занят), то раньше для такого выполнялось полное сканирование всех файловых структур, полный обход всего дерева каталогов, что на современных терабайтных дисках займет слишком много времени. Проще заглянуть в журнал, посмотреть незавершенные операции и поудалять их все (недописанные остатки ваших файлов или конфликты), но восстановив целостность файловой системы за секунды.
mvv-rus
27.07.2023 12:50+2По умолчанию, да, журналируемая файловая система целостность содержимого обычных файлов от сбоев при их записи не защищает.
Однако журналируемая файловая система может предоставлять сервис, позволяющие приложению сохранять файлы транзакционно, по принципу "все или ничего". Такой сервис, в частности, в Windows предосталяет NTFS, начиная с Vista: TxF,
alan008
27.07.2023 12:50По поводу TxF - спасибо за упоминание, впервые услышал о таком! Это действительно кроличья нора )
saboteur_kiev
27.07.2023 12:50И в первом же абзаце указано, что возможно будущие версии виндовс могут не поддерживать транзакции...
saboteur_kiev
27.07.2023 12:50Интересно, но по сути это практически ничего не меняет.
В журнал пишется начало операции, потом в журнале пишется что операция завершена.
Какая именно это была операция - запись файла, удаление, перемещение, компрессия, шифрование, создание снапшота - это уже вторично.
Если операция прервется по какой-либо причине, основной способ все починить - подчистить все шаги незавершенной операции.
Komrus
27.07.2023 12:50А давайте вспомним ещё первые Windows и запись на дискету...
Тоже много чудес с потерей данных было из-за кешей...
MTyrz
27.07.2023 12:50+5smartdrv.exe
И (для особых эстетов) с какой скоростью без него ставилась NT 4.0
lamerAlex
27.07.2023 12:50+1Ой ... Установка NT запускалась из DOS?
MTyrz
27.07.2023 12:50+2Скажем так: сам я грузился с досовой дискеты с драйвером CD-ROM (смартдрайв я в autoexec прописал, чтобы не забывать), потом переходил на CD, запускал файл, емнип, winnt.exe — и вперед. Но у меня был… хм… неофициальный дистрибутив.
Официально же… беглый гуглеж показывает примерно такое:Наиболее типичный вариант локальной инсталляции состоит в использовании компакт-диска и трех загрузочных дискет, прилагаемых к дистрибутиву на компакт-диске. Дистрибутив, целиком поставляемый на дискетах 3.5 дюйма, состоит из слишком большого числа дискет и поэтому используется редко.
Похоже, что да, своего загрузчика там могло и вообще не быть. Но в точности я не знаю.
Если у вас есть компакт-диск, но нет стартовых загрузочных дискет, то они могут быть получены на начальной стадии инсталляции. Возможен также вариант инсталляции вообще без загрузочных дискет — для этого необходимо стартовать программы winnt.exe или winnt32.exe с ключом /B.lamerAlex
27.07.2023 12:50Посмотрел дистрибутив XP - действительно есть winnt.exe и судя по отказу запускаться действительно досовый или по кр. мере 16-битный. Вы правы.
MTyrz
27.07.2023 12:50Ну, ХР — это уже чертовски поздняя штука, смартдрайв ей точно не был нужен (а вот насчет 2к, кстати, меня берут некоторые сомнения), и она точно умела грузиться с собственного диска. Хотя могла и пытаться обновлять 9х: скорее всего, winnt.exe там для этого.
mvv-rus
27.07.2023 12:50Загрузка в XP/2K3 Server (в том числе и при первой инсталляции) была практически без изменений перенесена из исходной версии (с ntldr и boot.ini с его ARC-путями).
Изменение загрузчика произошло при переходе на Vista/2K8 Server.
K0styan
27.07.2023 12:50+1С 2000, насколько помню, такая же история, как с NT 4 была. Во всяком случае с 4 я дела не имел, а предостережение про смартдрайв в памяти сидит)
saboteur_kiev
27.07.2023 12:50+3Ой ... Установка NT запускалась из DOS?
Установка NT могла запуститься из дос и из виндовс.
truthseeker
27.07.2023 12:50Или с Windows NT предыдущих версий с помощью winnt32.exe. В любом случае, чтобы установить Windows NT 4.0, нужно было иметь загрузочную дискету(а тогда она была у всех, кто устанавливал продукцию от MS), или одну из подходящих предыдущих ОС от MS.
Кстати, установка Windows 9.x тоже запускалась, по сути, из DOS. Или с предыдущей версии Windows 9.x. Емнип, так до самого ME включительно было. Стандартная, по тем временам, практика.
saboteur_kiev
27.07.2023 12:50Или загрузочный CD-rom
или просто сделать загрузочный HDD с DOS другого HDD - в процессе установки NT оно предлагало конвертнуть файловую систему в NTFS
MountainGoat
27.07.2023 12:50+2Зачем вспоминать? С флешками до сих пор всякая муть творится.
net_racoon
27.07.2023 12:50В линуксах да. Отмонтировал флешку и ждешь когда он засинкается. А почему, кстати, нельзя ее монтировать с O_SYNC?
DaemonGloom
27.07.2023 12:50Можно монтировать хоть с sync (будет значительно медленнее работать), хоть с flush (быстрее sync, но медленнее обычного кэширования).
На windows флешки с ntfs тоже будут работать с кэшем и медленно отключаться (или говорить, что устройство занято и пока извлечь нельзя).net_racoon
27.07.2023 12:50Ну вот тут непонятно, зачем на флешке кэш? Мы же там данные приложений не храним, а качаем/заливаем файлы. Почему не делать это напрямую?
garwall
27.07.2023 12:50все сложнее. одноплатники часто грузятся с флэшек, лайв-образа с persistent storage тоже дело привычное.
Naves
27.07.2023 12:50Ну вот предположим, что пользователь редактирует документ, расположенный на флешке через обычный MS Word. Редактор при работе создает временный файл в каталоге с документом, и вот вдруг, мы уже там данные приложений храним.
Пользовательский опыт, он такой.
domix32
27.07.2023 12:50Не сказать что я ими шибко часто пользуюсь, но за 15 лет их использования проблем с ними было пересчитать по пальцам. Во времена XP пару раз SD флешка вайпалась из-за неизвлеченности устройства, но с появлением семёрки у меня только одна бракованная флешка отъехала, остальные пусть медленно, но работали без проблем.
Zara6502
27.07.2023 12:50+9сначала ломанулся проверять не перевод ли это западной статьи, за кордоном столько людей удивляется простым вещам, что я уже перестал давно удивляться. смотрю вроде имя русское, но статья на английском и автор пишет что проживает в Лондоне.
я о кешировании записи узнал в 1992 году на компьютере Искра 1030, чуть позже меня научили писать в NC по F2 команду сброса кеша smartdrv перед выключением ПК. А в нулевых мы вырубали кеш для флешек в Линуксе, ну не нравилось нам сидеть ждать когда данные запишутся после размонтирования тома.
как может человек знать линукс на уровне глубже двойного клика по ярлыку и не знать про кеширование записи?
poxvuibr
27.07.2023 12:50+10как может человек знать линукс на уровне глубже двойного клика по ярлыку и не знать про кеширование записи?
Это знание приходит после того, как он в первый раз выдёргивает из компа флешку, на которую скопировал файлик гига где-нибудь на 4 )))
GospodinKolhoznik
27.07.2023 12:50+8На эту тему есть даже древний анекдот:
Начальник - секретарю:
- Катенька, дорогая, перепиши месячную отчетность нашим партнерам, они сейчас к тебе подойдут.
- Добрый день, это вам переписать 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
- Возьмите пожалуйста!
Партнеры. - Них..$%#@я себе!!!
- Что такое?!... Я опять отмонтировать забыла?!
poxvuibr
27.07.2023 12:50+5Что такое?!... Я опять отмонтировать забыла?!
Ничего страшного, sync не забыла, так что нормально всё будет ))
gurux13
27.07.2023 12:50Не, просто мы забыли, на дискете была очень важная информация, но вы же только скопировали на дискету, вы ж её не форматировали, хе-хе?
А ещё, кажется, точка с запятой в find лишняя, не? Которая после '{}'.
saboteur_kiev
27.07.2023 12:50имхо там вообще кавычки потеряны. С -name все потенциально готово поломаться, поскольку если в текущем катаолге будет два подходящих по маске файла, будет синтакс еррор
K0styan
27.07.2023 12:50+2Хорошо раньше было, когда все флэшки со светодиодами были) Объяснить, что не надо выдёргивать, пока не перестанет моргать, обычно очень просто получалось.
Reminded208
27.07.2023 12:50Спасибо за статью. Интересно, отличаются ли подходы записи на диск в разных дистрибутивах?
Wesha
27.07.2023 12:50+3Учитывая эту трату, мы лучше выполним одну большую операцию записи на 1 мегабайт, чем сто небольших записей по 10 килобайтов каждая.
Я сейчас взорву Вам мозг, но, ВНЕЗАПНО, диск не может записать один байт, он может прочитать 1024 байта (а сейчас — 4096, называется — "сектор", минимально адресуемая единица), изменить в них 1, и записать обратно {{1023|4095} старых + 1 новый}, причём уже при следующем обороте диска, потому что пока читали — сектор уже ушёл из-под головки, и надо ждать, пока он там опять появится.
lorc
27.07.2023 12:50+5Обычно размер сектора (блока) все же 512 байт.
На флеш накопителях все еще сложнее, ибо там есть отдельное понятие erase block - минимальный блок который можно стереть. И он может быть вообще недетских размеров - например 256кб. Вот там перезаписать один байт может быть ОЧЕНЬ дорого.
AlB80
27.07.2023 12:50SSD прочитает сектор 4096 байт, запишет его в новый блок и поправит таблицу трансляции.
Когда в старом блоке неиспользуемое место (стирание TRIMом или перезапись) превысит некий процент или SSD будет остро нуждаться в свободном месте для записи (нужны чистые блоки), то остатки информации с блока будут скопированы в новый и блок уйдёт на стирание.
Итого: для SSD записать один байт не дороже HDD.
По времени = чтение+запись сектора.
По ресурсу = чтение+запись сектора.Naves
27.07.2023 12:50Нет. Вы просто не сталкивались с ситуацией, когда после некоторого обьема записи данных, скорость SSD резко падает до совсем неприличных значений, и скорость записи SSD становится хуже древних HDD.
Извините, но вы же сами себе противоречите: пишете про то, что требуются операции на работу с таблицой трансляции, и дефрагментации данных пользовательских секторов во внутренних блоках памяти. Но при этом "для SSD записать один байт не дороже HDD"
saboteur_kiev
27.07.2023 12:50+2Обычно размер сектора (блока) все же 512 байт.
Это было ДО 2011 года. Все производители дисков перешли на 4к сектора. В промежуточном варианте могло быть что на уровне железа еще использовались 512-байтные сектора, но контроллер уже оперировал виртуальными 4к секторами.
Ну и уже прошло более 10 лет. ВСЕ HDD уже нативно 4к.
Флеш не знаю, там могут быть эксперименты, но я уверен что только в бОльшую сторонуи да "сектора (блока)" - не путайте блок и сектор. Блок или кластер - это уровень файловой системы. Сектор - низкоуровневый, туда уже не лазят с тех пор как контроллер переехал с материнки в диск.
DaemonGloom
27.07.2023 12:50+1Если вы купите сейчас диск и спросите его о геометрии — то в большинстве случаев вам скажут что-то подобное. И не важно, кто там производитель.
"Sector size (logical/physical): 512B/512B"
Впрочем, ничего не скажу по SMR дискам — предпочитаю стандартные.saboteur_kiev
27.07.2023 12:50Парочка аргументов.
Переход из 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б? Хотел бы убедиться что такое еще существует на массовом рынке.Naves
27.07.2023 12:50>Можете навскидку привести хотя бы парочку устройств, выпущенных за
последние лет 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: Enabledsaboteur_kiev
27.07.2023 12:50в SSD нет секторов как в hdd.
Ибо нет намагниченных областей, для которых нужна разметка, gap, crc области.
Такие вещи, как размер сектора и вообще смысл перехода с 512б на 4к формат в принципе нельзя применять к SSD накопителям, которые дискретны изначально.В SSD Есть микросхемы памяти, есть контроллеры этих микросхем. и SSD не может считать байт или кусок микросхемы, он читается целиком. Я сомневаюсь что минимальный размер физического чипа памяти там такой маленький. В современных условиях проще штамповать микросхемы наверное по мегабайту хотя бы, а наружу проецировать логические 512б для совместимости, ибо на перформансе это не сильно отражается. наверное.
Но про потроха SSD я не готов говорить. Главное - Advanced Format не применим к SSD, там вообще смотреть на факторы влияющие на перформанс надо с другой позиции.
DaemonGloom
27.07.2023 12:50+1Хм, согласен, parted врёт. Если спросить smartctl, то система говорит про них "Sector Sizes: 512 bytes logical, 4096 bytes physical". И в описании пишут, что они 512e.
WD6003FRYZ-01F0D, WD40PURZ, st12000nm001g-2mv103saboteur_kiev
27.07.2023 12:50WD6003FRYZ - точно 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)mvv-rus
27.07.2023 12:50Эта совместимость лет 10-15 назад была важна для Windows Server (как сейчас — не в курсе). Потому что движок ESE (транзакционный NoSQL движок БД от MS, сначала он был чисто внутренним, потом его сделали публичным) довольно долго не умел поддерживать сектора размером кроме 512 байт (потому что он старый, делался где-то в середине 90-х), а на этом движке были реализованы многие внутренние БД Windows Server (например, база AD), а также MS Exchange.
Так что мне чисто по работе приходилось тогда следить, какие диски закупаются и как конфигурируются.
Naves
27.07.2023 12:50+2А какой взрыв мозга начинается, если задуматься над тем, а что будет если выключить электричество именно в момент перезаписи физического сектора на диске.
А если это SSD, у которого размер сектора на самом деле не 512 и не 4096 байт...
N1X
27.07.2023 12:50+1А он не перезаписывает сектор, он его переносит в свободный с модификацией нужной части. После завершения - пометит старый, как подлежащий стиранию. Это нужно для выравнивания износа, иначе он в часто используемых местах дырку протрет. Соответственно более менее сносно всё. Но вот алгоритмы работы с флешем у всех производителей свои, и кеши сейчас объёмные, поэтому это тёмный лес, конечно...
OlegZH
27.07.2023 12:50А какой взрыв мозга начинается, если задуматься над тем, а что будет если выключить электричество именно в момент перезаписи физического сектора на диске.
Подождите. А что делать с необходимостью экстренно парковать головки чтения-записи, при резком обрубании электричества. Раньше писали, что... Я уже и забыл, что именно. Короче! При штатном отключении головки паркуются куда надо. А что происходит при аварийном отключении? Даже и знать не хочется... :-(
nidalee
27.07.2023 12:50+1При штатном отключении головки паркуются куда надо. А что происходит при аварийном отключении?
Тоже самое, ЕМНИП. У них хватает заряда припарковаться.
Wesha
27.07.2023 12:50+6что будет если выключить электричество именно в момент перезаписи физического сектора на диске.
Ничего не будет. В разъёме ATX есть линия PWR_OK ("питание в порядке"). В нормальном рабочем состоянии на нём высокий уровень. При пропадании напряжения в сети уровень переключается на низкий, и все устройства получают команду "мы падаем, всем приготовиться". Винчестеры аварийно сбрасывают свои внутренние кэши на диск — энергии, запасённой коденсаторами блока питания, на это хватает. В крайнем случае у винчестера в расоряжении есть ещё и энергия вращающихся пластин — мотор шпинделя переходит в режим генератора. Когда дело сделано, отключаются электромагниты привода головок, и они под действием пружины сами отходят в парковочную позицию. Так что "партия всё предусмотрела, товарищи, вы полетите ночью" (c).
Naves
27.07.2023 12:50+2Это все городские легенды. (с)
1) команду "мы падаем, всем приготовиться"
а можно ссылочку на такую команду, что она успевает передаться? Совершенно непонятно, кто успевает ее отправить и каким образом.
Я не спорю есть штатная команда, которая отправляется перед штатным выключением, но не в данном случае.
2) Винчестеры аварийно сбрасывают свои внутренние кэши на диск — энергии, запасённой коденсаторами блока питания, на это хватает.
Простите чьего блока питания? Китайского БП на 300 китайских ватт с высохшими конденсаторами? Внутри HDD блок питания условный, там просто стабилизаторы напряжения для рабочих напряжений электроники.
4) сбрасывают свои внутренние кэши на диск
кэши дисками не записываются при потере питания. Вам об этом даже в статье написали. Если хотите надежно записать данные на физический носитель, используйте при записи флаг SYNC, тогда данные сразу попадут на физическую ячейку памяти носителя.
Но некоторые носители при определенных условиях могут игнорировать этот флаг, и сразу рапортовать о том, что записали. Например, так делают SSD c конденсаторами. НО не все SSD имеют конденсаторы, и некоторые SSD без конденсаторов ведут себя, как будто имеют резервный запас энергии, те банально обманывают систему, и в случае сбоя потеряют данные.
Другой пример, есть RAID контроллеры с батарейкой. Некоторые думают, что это батарейка, для того чтобы диски успели записать данные. Так вот НЕТ. Эта батарейка для питания чипов памяти кэша контроллера. Данные из кеша будут записаны при следующем включении. И если питание не вернется через N-часов, то данные в кеше будут потеряны.
И вот кстати, именно RAID контроллеры с батарейкой при настройках по умолчании игнорируют флаг SYNC предполагая, что батарея заряжена и работает штатно. Пока внезапно не выяснится, что самопроверка контроллера не выявила, что батарея не сохраняет заявленное количество энергии.
5) мотор шпинделя переходит в режим генератора
а можно ссылочку? имхо городская легенда. Если мотор переключить в режим генератора, диски еще быстрее остановятся, а у нас как бы обратная задача - успеть записать данные в режиме, когда скорость дисков уже невозможно поддерживать в штатных пределах.
Из практики при выключении диска в момент записи, сектор успевается пометится как сбойный и увеличивается счетчик Current Pending Sector Count. При следующем чтении этого сектора, если все ок, то сектор возвращается в работу, а счетчик Pending уменьшается.
Wesha
27.07.2023 12:50а можно ссылочку на такую команду, что она успевает передаться?
А в чём проблема-то? На всё про всё есть ещё примерно 0,1 секунды — это при 5400 RPM — порядка 90 оборотов шпинделя.
кто успевает ее отправить и каким образом.
Гуглите PWR_OK, и будет вам ЩАСТЬЕ. Сказано ж — это отдельная линия в ATX разъёме. Уровень меняется с высокого на низкий — матплата приступает к тушению света.
Китайского БП на 300 китайских ватт с высохшими конденсаторами?
С китайского БП все взятки гладки — скажет "ну не шмогла я".
кэши дисками не записываются при потере питания.
Кэши ОС, естественно, не записываются. Внутренние кэши драйва — те, которые расположенвы на плате самого винчестера — насколько мне известно, таки записываются (естественно, если в момент потери питания шла активная запись — в противном случае и записывать-то, собственно, ничего не надо.)
как бы обратная задача - успеть записать данные в режиме, когда скорость дисков уже невозможно поддерживать в штатных пределах.
А какая разница, штатные там пределы или не штатные? Тут уже аварийная ситуация, поддержание обещанной спецификацией скорости обмена уже никого не волнует. А синхрометки с дисков никуда ведь не делись.
Naves
27.07.2023 12:50+2Я в курсе про PWR_OK. Насколько я помню, этот сигнал использовался для проверки готовности к старте системы, и если его коротнуть на землю, то система мгновенна уходила в ребут.
Hidden text
В интернете кто-то не прав.
Давайте зафиксируем предмет спора.
Те вы утверждаете, что при потере сигнала PWR_OK материнская плата каким-то образом передает сигнал по какой-то шине подключенным устройствам, что-то вроде "я потеряла питание, вы там как-нибудь сами".
Naves
27.07.2023 12:50-1>Внутренние кэши драйва — те, которые расположенвы на плате самого винчестера — насколько мне известно, таки записываются
насколько мне известно, НЕ записываются. Особенно если это обычные потребительские диски, а не диски уровня 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.В следующей версии просто по умолчанию будет отключен кеш. и все. И нет никаких конденсаторов.
Wesha
27.07.2023 12:50+1винчестера
SSD теряет данные
Вы совсем-совсем никаких несоответствий тут не видите? Точно?
Naves
27.07.2023 12:50Обычные дешевые потребительские SSD не содержат конденсаторов, достаточных для записи из кеша.
Если уж SSD не успевает записать данные из кеша, то HDD тем более не сможет.
>Вы совсем-совсем никаких несоответствий тут не видите? Точно?
Не вижу. Точно.
Wesha
27.07.2023 12:50Если уж SSD не успевает записать данные из кеша,
Простите, а в каком конкретно месте у SSD маховичный накопитель энергии?
то HDD тем более не сможет.
Ну да, конечно, HDD ж нужно стереть десяток окружающих дорожек, чтобы одну перезаписать...
Naves
27.07.2023 12:50>А какая разница, штатные там пределы или не штатные? Тут уже аварийная ситуация, поддержание обещанной спецификацией скорости обмена уже никого не волнует. А синхрометки с дисков никуда ведь не делись.
Действительно никакой разницы, что головки и управляющий софт, рассчитаны читать и записывать на штатной скорости в определенных отклонениях.
И теперь вы предлагаете "заинженерить некий алгоритм дозаписи данных" в аварийной ситуации?А вам инженеры ответят. Если хотите надежно писать, используйте флаг 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
DaemonGloom
27.07.2023 12:50Другой пример, есть RAID контроллеры с батарейкой. Некоторые думают, что это батарейка, для того чтобы диски успели записать данные. Так вот НЕТ. Эта батарейка для питания чипов памяти кэша контроллера. Данные из кеша будут записаны при следующем включении. И если питание не вернется через N-часов, то данные в кеше будут потеряны.
Чаще это батарейка для записи DRAM кэша во встроенный флэш. Да и ту уже чаще заменяют на ионистор, которого на запись точно хватает. Так что современный контроллер нормального производителя ничего не потеряет даже при долгом отсутствии питания.
saboteur_kiev
27.07.2023 12:50Совершенно непонятно, кто успевает ее отправить и каким образом.
Проблема парковки головок сейчас отсутствует. Все производители HDD масс сегмента выпускают диски, которые могут нормально запарковаться в случае потери питания.
Сохранить данные - тут уже вряд ли. В любом случае внутренняя память в дисках чаще служит для ускорения чтения, чем записи, и для записи обычно используется очень и очень кратковременно, на уровне расчета траектории перемещения головок, чтобы использовать параллельную запись, если такое есть
mr_welk
27.07.2023 12:50Когда деревья были большими, такого не было и наблюдать пропилы от головок на пластинах при аварийном отключении приходилось. Правда и диски тогда были с обьёмами по 40 мегабайт :)
Wesha
27.07.2023 12:50Было такое. Эх... "Искра-1030" с MFM-винчестером на то ли 20 мегабайт, то ли на 40, где передвижение блока головок производилось торчащим на всеобщее обозрение шаговиком... и перед отключением питания надо было запускать утилиту принудительной парковки головок...
Tarakanator
27.07.2023 12:50он может прочитать 1024 байта, изменить в них 1, и записать обратно
С черепичной записью так уже нельзя
Кроличья нора углубляется.
Dolios
27.07.2023 12:50+1Удивитесь ли вы, если я скажу, что запись 1 байта вызывает запись на диск 65 тысяч байтов?
Нет, мы знаем про сектора. Еще вирусы под DOS умели себя в последнем секторе файла прятать, чему тут удивляться?
ivanstor
27.07.2023 12:50+3Главное, что я извлек из этой статьи: у автора, похоже, эпилепсия. Поскольку его постоянно трясет, с каждой новой страницей книги "Linux для полных дебилов".
saboteur_kiev
27.07.2023 12:50+6Удивитесь ли вы, если я скажу, что запись 1 байта вызывает запись на диск 65 тысяч байтов?
Сильно удивлюсь.
Ибо современный размер сектора - 4 кб, и в нормальной ситуации, запись выполняется по секторам.
Может быть, из-за того, что у вас было несколько операций записи, которые закешировались на уровне ОС или контроллера диска, и очередная запись 1 байта наконец повлекла запись всей цепочки, но это вы тогда хитрите.Если же у вас запись 1 байта на диск провоцирует запись 64к байт, что-то пошло не так. Или кто-то экспериментирует с ssd/флеш дисками - там под капотом могут быть нюансы.
P.S. Честно говоря, статья разочаровала. О банальных и давно известных вещах пишется во-первых с большим удивлением, во вторых с кучей неточностей и некорректностей, из-за чего новичок только запутается.
Тот же "файл это интерфейс" - нет, интерфейс это интерфейс, например handler это интерфейс.А файл и директория - это термины, которые обозначают определенные сущности на хранителе информации. Та же iNode это тоже не интерфейс, а способ организации posix файловой системы. В других файловых системах могут быть другие способы, FAT, MFT..
poxvuibr
27.07.2023 12:50Ибо современный размер сектора - 4 кб
Размер кластера в ФС тоже 4 килобайта по умолчанию. Но я, например в последнее время ставлю 64к, потому что на дисках в основном большие файлы. Вот тебе и запись минимум 64к )) . На одном диске вообще два мегабайта размер кластера. Там совсем большие файлы
vadimr
27.07.2023 12:50Кластер – это всего лишь единица распределения дискового пространства. Он не обязан записываться целиком.
domix32
27.07.2023 12:50Так больший размер сектора просто расширяет максимальное количество индексируемых данных. Ну и журнал вроде может поменьше сделать.
saboteur_kiev
27.07.2023 12:50ну в вашем случае вы же не удивляетесь, вы же специально такой размер выбрали.
Но насчет больших файлов - вопрос не в размере файла, а в размере операций записи/чтения. Если в этих файлах (например это базы данных) делаются мелкие изменения, то перфоманс вы себе таким образом ухудшили =)
А вот при линейном копировании/чтении (например онлайн кинотеатр, где нужно тупо линейно читать и писать большие объемы данных) - там большой размер кластера прямая выгода.
NutsUnderline
27.07.2023 12:50начало вроде для совсем начинающих а потом бац, O_SYNC и sync, термины, и открываем файл уже как лютые программисты.
placidity_master
27.07.2023 12:50+1Насколько медленные? Получение небольшой порции данных с SSD в тысячу раз медленнее, чем получение её из памяти.
прям в тысячу ? можно конкретные цифры ?
смотрю википедию:
Для памяти с эффективной частотой 3200 МГц (наибольшая частота,
изначально определённая стандартом) максимальная пропускная способность
составит 3200 × 8 = 25 600 МБ/chttps://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/
saboteur_kiev
27.07.2023 12:50Это автор вообще не пытался работать с SSD и памятью. Кроме памяти есть еще пропускная способность шины, а там может выясниться что все совсем уже и не так радужно.
Вдобавок, если брать не просто работу с памятью, а работу с каким-нить рамдиском, то его производительность вполне сопоставима с PCI-E NVMe, причем настолько сопоставима, что я отказался от использования рамдисков еще лет 5 назад.poxvuibr
27.07.2023 12:50Вдобавок, если брать не просто работу с памятью, а работу с каким-нить рамдиском, то его производительность вполне сопоставима с PCI-E NVMe
Возможно, если воткнуть nvme в слот, который находится "близко" к процессору, то скорость будет как-то сопоставима, но на чисто эмоциональном уровне я не верю )))
К тому же tmpfs не использует кеш о котором столько сказано в тексте статьи, а значит в должна быть побыстрее хотя бы формально.
И наконец, интесивная работа в tmpfs не истощает ресурс ssd ))
Хотя, конечно, было бы неплохо проверить, какая там разница по скорости будет, я только не уверен как это сделать. Могу ядро скомпилировать, но не уверен, что это показательно
voldemar_d
27.07.2023 12:50А что, к Windows и другим ОС всё перечисленное не относится? Так с дисками только Linux работает?
Wesha
27.07.2023 12:50Относится — просто от Windows никто великих свершений и не ожидает :)
mvv-rus
27.07.2023 12:50Ну, или все знают, что Windows просто работает, а как именно — это вам знать не обязательно :-)
toxicdream
27.07.2023 12:50Знать не обязательно и вы не узнаете - это про МакОС. И когда сломается - сами ничего не сможете сделать.
В Windows если что-то поломается, у пользователя появляется шанс узнать как это можно починить и возможно стать немного умнее.
0Bannon
27.07.2023 12:50Спасибо. Наконец-то я понял что такое inode, зачем буфер нужен и многое другое. Вот что значит простым языком и примерами объяснить сложные вещи. А то сколько ни читал книжки и всякие статьи - всё заумным языком объясняется.
saboteur_kiev
27.07.2023 12:50+2вы поняли неправильно. Автор сам неглубоко вник в суть вопроса, и что такое iNode пояснил некорректно.
iNode это просто метаинформация о записи в файловой системе, которая относится к конкретному файлу/директории или другой сущности файловой системы.
В винде для таких целей есть тот же MFS и directory entry там содержит больше данных. в FAT использовались directory entry и file allocation table.
Это просто потроха файловых систем, где хранятся данные о структуре и различных аттрибутах.В любом линуксе пиши
stat <path>
и тебе выдаст почти все что находится в конкретной iNodemvv-rus
27.07.2023 12:50В винде для таких целей есть тот же MFS и directory entry
В NTFS аналогом iNode является запись в MFT (Master File Table, полагаю, что у вас тут просто была описка). В элементе же каталога (directory entry) содержится ссылка на эту запись MFT для файла: в NTFS может быть несколько ссылок на один файл (то, что в Unix называется hardlink) по разным путям. В FAT ссылка всегда только одна, по единственному пути, информация о файле, включая первый назначенный ему кластер, содержится именно в элементе каталога по пути файла, а в FAT — односвязный список кластеров, назначенных файлу.
Wesha
27.07.2023 12:50+1iNode это просто метаинформация о записи в файловой системе
Чтоб далеко не ходить
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; };
lovecraft
Хорошая статья, но эта кроличья нора очень глубока
Могут быть баги в ядре и драйверах, из-за которых данные меняются в процессе записи https://habr.com/ru/articles/263893/
Могуи быть странности изменением данных во время сбороса страниц на диск https://habr.com/ru/articles/219295/comments/#comment_7493865
Даже у HDD сейчас есть свой кэш, который может жить своей жизнью (не говоря уж о SSD)
Нехорошие прошивки контроллеров могут возвращать управление после SYNC, не дожидаясь записи на диск
Прошивки СХД могут вообще игнорировать SYNC, надеясь на батарейную (суперконденсаторную) защиту кэша
И т.д.
MTyrz
Статья плоха даже для журнала "Мурзилка". И это точно не уровень хабра (хотя и по отличным от "Мурзилки" причинам). Хотя… медиахолдинг, говорите? Ну да, ну да...
Wesha
... могут быть баги в прошивке самого винчестера...