Comments 305
Пусть простит меня сообщество за холиварную тему, но все-таки…
Вопрос открытых или не открытых исходных кодов ОС — это вещь первостепенная. Сколько литров кофе потратили сотрудники компании во время реверс-инжиниринга, сколько нервных клеток пало в неравной борьбе с плохо протестированным кодом? И все равно пофиксить эту уязвимость типа «отказ в обслуживании» своими силами нельзя — исходников нет, и даже если написать свой фильтр-драйвер и проверять все вызовы NtCreateFile, то для такого драйвера нужна подпись Майкрософт, а она есть не у всех.
Если бы исходники были открыты, достаточно было бы взять отладчик, поставить брейкпоинт, заменить пару строчек, пересобрать модуль и готово.
Вопрос открытых или не открытых исходных кодов ОС — это вещь первостепенная. Сколько литров кофе потратили сотрудники компании во время реверс-инжиниринга, сколько нервных клеток пало в неравной борьбе с плохо протестированным кодом? И все равно пофиксить эту уязвимость типа «отказ в обслуживании» своими силами нельзя — исходников нет, и даже если написать свой фильтр-драйвер и проверять все вызовы NtCreateFile, то для такого драйвера нужна подпись Майкрософт, а она есть не у всех.
Если бы исходники были открыты, достаточно было бы взять отладчик, поставить брейкпоинт, заменить пару строчек, пересобрать модуль и готово.
В теории да. На практике мы имеем дело с тем, что проекты с открытым исходным кодом часто содержат ошибки, которые опытный разработчик никогда не допустит. Например, также имею опыт и с Linux. Для серверов и построения устройств на его базе — незаменимая вещь. Для desktop решений, говоря примитивно, ад. Т.к. сильно не хватает механизмов, которые есть в Windows. Везде есть как плюсы, так и минусы. Не соглашусь с тем, что однозначно можно утверждать, что открытые исходные коды, явный плюс.
проекты с открытым исходным кодом часто содержат ошибки, которые опытный разработчик никогда не допустит
В проприетарном ПО всё то же самое, только мы этого не видим, потому что код закрытый, ваш кэп :)
А неготовность линукса для десктопа связана не с открытостью, а с бесплатностью (даже какому-нибудь каноникалу не хватает ресурсов, в первую очередь денег на программистов, чтоб исправить всё и сразу) (хотя можно сказать, что бесплатность это следствие открытости, но вроде не всё так просто)
Но я ведь и не писал, что Linux лучше Widows и не сравнивал функционал. Я писал, что продукты с открытым кодом имеют преимущества перед закрытыми, когда речь идет о быстром исправлении ошибок малой командой разработчиков.
Я их тоже не сравнивал. Как я говорил, и там и там есть как плюсы, так и минусы. На счет преимущества, как показывает практика, это не добавляет скорости разработки. Опять же, от случаю к случаю. Важно понимать что все мы имеем в той или иной степени, разный опыт. И в первую очередь я рассказываю о своем.
> Я писал, что продукты с открытым кодом имеют преимущества перед закрытыми, когда речь идет о быстром исправлении ошибок малой командой разработчиков.
Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте».
Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте».
Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте»
Эта позиция всё же оказывается чуть лучше и понятнее чем "вам надо — ждите, держитесь там и всё такое".
Всё же разработчик open source решения ничего не должен конечному пользователю (хотя и с коммерческими, если почитать лицензию, ситуация примерно такая же, но вы ещё и деньги платите). Но хотя бы есть шанс, что если проблема задевает не только вас, то кто-нибудь когда-нибудь может её решить. Или можно кому-нибудь заплатить за решение этой проблемы, как вариант.
Я с вами соглашусь. Просто хотел сказать что открытый код != гарантированное исправление ошибок.
Зато открытый код — наличие возможности У ВАС ЛИЧНО при наличии навыков исправить проблему "здесь и сейчас".
Вот возьмём две ситуации:
Slack и Telegram.
В первом меня очень расстраивал баг, заключавшийся в том, что при нажатии Alt+Shift открывалось меню (Alt) и выбирался фиг пойми какой пункт (или, рандомно, никакой, но при быстром машинальном переключении раскладки во время печати, когда успеваешь напечатать полтора слова прежде, чем от глаз к рукам поступит сигнал о том, что на экране что-то не то, какая-то "буква" нет-нет, да и матчила какой-то из биндингов в меню и активировала чёрт-те что.
Т.к. код у их приложения закрытый (не смотря на то, что это всего лишь кастрированный хромиум с парой кастомных js-скриптов), всё, что мне оставалось после репорта — это ждать пару десятков версий, пока наконец соизволили починить...
Во втором меня очень расстраивало что в широкоэкранной (да и в неширокоэкранной тоже, но в этой особенно) разметке балуны (не знаю, как правильно эти прямоугольники по-русски назвать) с текстом имеют слишком маленький лимит ширины и в итоге любой большой текст (особенно вставляемый код) превращается в кашу.
И разработчики вот уже год как игнорируют тонны багов и даже закрыли пуллреквест с патчем, исправляющим это (и он уже протух относительно кода).
Но… Т.к. код открыт — ничто не помешало мне по мотивом протухшего пулл-реквеста сделать свой патч и добиться желаемого эффекта: текст перестал искусственно сжиматься по горизонтали якобы для улучшения читаемости (чьей, интересно? явно не моей!).
Или, опять же, 2Gis против всё того же телеграма.
Оба патчат Qt5 для того чтобы собрать своё приложение (ну, нравится людям, видимо, патчить инструменты).
Но у 2Gis код закрыт и поэтому остаётся только страдать и иметь не работающее под линуксами отличными от Ubuntu приложение (потому что кроме ситуации с патченными Qt5 и крахом из-за отсутствия использованных костылей в системной версии, они ещё и слинковали бинарник одновременно с двумя версиями ICU).
Телеграмовцы тоже любители пропатчить Qt, но… код у них открытый и поэтому это позволило мне (и представителям других дистрибутивов) написать набор патчей для отвязывания его от необходимости как патчить системные Qt, так и билдить свою статическую копию.
В случае с 2Gis же… Я уже года два-три, если не больше, репорчу-репорчу, но т.к. Linux не ЦА-платформа — nobody cares.
Так и живём :)
> Зато открытый код — наличие возможности У ВАС ЛИЧНО при наличии навыков исправить проблему «здесь и сейчас».
>… при наличии навыков…
Я действительно рад что у вас навыки для исправления багов, к сожалению моих навыков программирования (веб + МК) хватает только для того чтоб написать багрепорты и ждать у моря погоды, что в линуксе что в винде.
>… при наличии навыков…
Я действительно рад что у вас навыки для исправления багов, к сожалению моих навыков программирования (веб + МК) хватает только для того чтоб написать багрепорты и ждать у моря погоды, что в линуксе что в винде.
В случае с 2Gis же… Я уже года два-три, если не больше, репорчу-репорчу, но т.к. Linux не ЦА-платформа — nobody cares.
Они, видимо, решили вообще уйти в онлайн и на мобильные платформы (их очередной ответ в вк группе)
есть шанс, что если проблема задевает не только вас, то кто-нибудь когда-нибудь может её решитьЭто верно и для открытого и для закрытого кода. Причём, вероятность иногда выше в проектах с закрытым исходным кодом — баги фиксятся чаще, тестирование осуществляется лучше и так далее.
Исправление ошибок в системе с открытыми исходниками тоже может быть осложнено лицензией, прямо запрещающей модификацию кода не автору, или требованием подписи новособранных бинарников.
Конечно, можно отослать патч правообладателю, чтобы он учел его в следующей версии. Это уже плюс.
Но если автор забил на продукт, то ограниченная лицензия на продукт с открытыми исходниками может существенно осложнить возможность исправления ошибки.
Короче, открытые исходники — это хорошо в плане исправления ошибок (если исходников нет, то даже «надо — сделай сам» сильно осложнено необходимостью реверс-инженеринга и, частенько, необходимостью сертификации получившегося результата), но совсем не панацея.
Конечно, можно отослать патч правообладателю, чтобы он учел его в следующей версии. Это уже плюс.
Но если автор забил на продукт, то ограниченная лицензия на продукт с открытыми исходниками может существенно осложнить возможность исправления ошибки.
Короче, открытые исходники — это хорошо в плане исправления ошибок (если исходников нет, то даже «надо — сделай сам» сильно осложнено необходимостью реверс-инженеринга и, частенько, необходимостью сертификации получившегося результата), но совсем не панацея.
Исправление ошибок в системе с открытыми исходниками тоже может быть осложнено лицензией, прямо запрещающей модификацию кода не авторуЕсли лицензия позволяет править исходники только автору, то это — не система с открытыми исходниками. Microsoft для таких случаем использует термин shared source
Касательно РФ, закон позволяет вносить изменения в программу, которые исправляют баги или адаптируют её для конкретного применения. Главное не распространять изменённую копию. И закон имеет приоритет над лицензионным соглашением.
Закон мог бы иметь приоритет, но… не имеет. Дело в том, что в соответствующий пункт несколько лет назад была внесена маленькая поправочка. Было:
И эта маленькая добавка в конце оччено существенно изменила-таки смысл закона, согласитесь? Вы лицензионное соглашение на Windows читали? Ну так просветитесь…
Лицо, правомерно владеющее экземпляром программы для ЭВМ… вправе без разрешения автора или иного правообладателя… большой список всякого разногостало:
Лицо, правомерно владеющее экземпляром программы для ЭВМ… вправе без разрешения автора или иного правообладателя… большой список всякого разного, если иное не предусмотрено договором с правообладателем
И эта маленькая добавка в конце оччено существенно изменила-таки смысл закона, согласитесь? Вы лицензионное соглашение на Windows читали? Ну так просветитесь…
UFO just landed and posted this here
Является, естественно. Но там та самая «маленькая добавка в конце» в соответствующей статье в Гражданском кодексе на самом деле очень размытая: «Применение положений, предусмотренных настоящей статьей, не должно противоречить обычному использованию программы для ЭВМ или базы данных и не должно ущемлять необоснованным образом законные интересы автора или иного правообладателя.»
Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».
Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».
Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».Это в части декомпиляции, создания резервных копий и прочего.
«Внесение в программу для ЭВМ или базу данных изменений» и «исправление явных ошибок» — это пункт 1280 подраздел 1 параграф 1. В нём — никакой размытости: «если иное не предусмотрено договором с правообладателем» и точка.
Спасибо за информацию, я не знал об этой поправке.
Ещё бы без уничижительно-поучительного тона, было бы совсем хорошо.
Ещё бы без уничижительно-поучительного тона, было бы совсем хорошо.
UFO just landed and posted this here
У Linux всё очень плохо с поддержкой железа и разных низкоуровневых фишек. Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
Вот взять хотя бы NTFS, раз уж статья о ней. Как-то обнаружил, что на внешнем USB-диске появились ошибки: имя одного из файлов сменилось на кашу из символов, и удалить этот файл не выходит — пишет, что файл повреждён.
В винде я бы сделал chkdsk и всё, а в Linux вдруг с удивлением обнаружил, что там полностью отсутствует мало-мальски функциональный инструмент для исправления NTFS-ошибок. Всё, что может мне предложить Linux — это утилиты из комплекта NTFS-3G, которые ntfsfix и ntfsck. И обе они исправляют лишь небольшое подмножество ошибок — фактически, только чтобы файловая система после фикса вообще могла смонтироваться. Полез гуглить — везде советуют загрузиться из-под винды и пофиксить.
Ну весело… Получается, что в Linux нет полной поддержки одной из самых распространённых домашних файловых систем? Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень. У FAT32 ограничение на размер файла. И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?
Вот взять хотя бы NTFS, раз уж статья о ней. Как-то обнаружил, что на внешнем USB-диске появились ошибки: имя одного из файлов сменилось на кашу из символов, и удалить этот файл не выходит — пишет, что файл повреждён.
В винде я бы сделал chkdsk и всё, а в Linux вдруг с удивлением обнаружил, что там полностью отсутствует мало-мальски функциональный инструмент для исправления NTFS-ошибок. Всё, что может мне предложить Linux — это утилиты из комплекта NTFS-3G, которые ntfsfix и ntfsck. И обе они исправляют лишь небольшое подмножество ошибок — фактически, только чтобы файловая система после фикса вообще могла смонтироваться. Полез гуглить — везде советуют загрузиться из-под винды и пофиксить.
Ну весело… Получается, что в Linux нет полной поддержки одной из самых распространённых домашних файловых систем? Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень. У FAT32 ограничение на размер файла. И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?
Если я правильно помню, тут проблема не совсем в линуксе, NTFS абсолютно закрытая ФС без какой-либо официальной документации, и то, что она доступна в линуксе хоть как-то, уже очень большое достижение (если я не прав, буду рад узнать об этом)
И на чём же к примеру хранить фильмы
exFAT? Правда, я не интересовался, чё там с исправлением ошибок)
С exFAT довольно странная вещь. Я, правда, пару раз обжёгшись больше с ней не разбирался, возможно, не умею её готовить. А случилось вот что: отформатировал флешку дома (Win7 x64), принёс на работу – винда (Win7 x64) её не понимает. Ладно, переформатировал на работе, всё стало хорошо, принёс домой – моя винда её не понимает.
Отформатированную дома флешку, кстати, прекрасно понимала домашняя же XP SP2 с апдейтом для поддержки exFAT.
Отформатированную дома флешку, кстати, прекрасно понимала домашняя же XP SP2 с апдейтом для поддержки exFAT.
exFAT отвратительная файловая система с точки зрения надежности.
1. в отличие от FAT16,32 таблица заполняется, только для фрагментированных файлов.
2. таблица FAТ в одном экземпляре. Кроме этого в некоторых ОС при форматировании (создании таблицы) не удосуживаются очищать область, которую будет занимать таблица. Основной структурой контроля занятого пространства считают Bitmap. В итоге анализируя разрушения.
В общем при незначительных разрушения директории можем получить существенные потери при попытке воспользоваться средствами исправления ошибок (потери большие нежели в случае FAT32).
ExFAT использовать, только для хранения данных потеря которых не будет критична.
1. в отличие от FAT16,32 таблица заполняется, только для фрагментированных файлов.
2. таблица FAТ в одном экземпляре. Кроме этого в некоторых ОС при форматировании (создании таблицы) не удосуживаются очищать область, которую будет занимать таблица. Основной структурой контроля занятого пространства считают Bitmap. В итоге анализируя разрушения.
В общем при незначительных разрушения директории можем получить существенные потери при попытке воспользоваться средствами исправления ошибок (потери большие нежели в случае FAT32).
ExFAT использовать, только для хранения данных потеря которых не будет критична.
И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?
Ext4, XFS, Btrfs. Не вижу в них экзотики.
в Linux нет полной поддержки одной из самых распространённых домашних файловых систем
Потому что ФС закрытая, обложенная патентами и авторскими правами. Сама Microsoft помогать даже документацией не желает.
Ext4, XFS, Btrfs
Чё там с поддержкой их приставками, телевизорами, виндами?
Чё там с поддержкой их приставками, телевизорамиТрясите производителей, однако. Все эти приставки и телевизоры используют Linux и «внутри себя» используют ext3/ext4 и xfs, однако на внешних HDD их не поддерживают — и кто в этом виноват? Linux?
виндами?Если винда у вас есть, то и виндовый chkdsk у вас есть, не вижу проблемы.
и кто в этом виноват? Linux?
В контексте данной ветки неважно, кто виноват, важно, что линукс и используемые им технологии, как ни крути, не готовы для повседневного использования)
виндовый chkdsk у вас есть
Он умеет проверять и исправлять «Ext4, XFS, Btrfs»?
А за что заминусовали-то, да ещё и в карму? Я какую-то неправду сказал?
В контексте данной ветки неважно, кто виноватИзвините, но если вам неважно — кто виноват в проблеме, то как вы собираетесь её исправлять? Началось-то всё с того, что в Linux, оказывается отвратительные и никуда не годные технологии.
важно, что линукс и используемые им технологии, как ни крути, не готовы для повседневного использования)Потому что производители «приставок и телевизоров» целенаправленно и сознательно делают невозможным их использование.
Вы уж меня извините, но… это не техническая проблема и технического решения она не имеет!
Он умеет проверять и исправлять «Ext4, XFS, Btrfs»?Нет, но в этом случае вас не будет напрягать тот факт, что поддержка NTFS в Linux, по понятным причинам, ограниченная.
но если вам неважно — кто виноват в проблеме
Передёргивать не надо, я же указал — в контексте данной ветки.
Потому что производители «приставок и телевизоров» целенаправленно и сознательно делают невозможным их использование.
Ни капельки не споря с этим, вынужден ещё раз заметить, что из-за этого линуксовые технологии непригодны для конечных пользователей, и форматирование флешек для них «Ext4, XFS, Btrfs» по-прежнему неприемлемо, потому что эту флешку никто не сможет прочитать.
вас не будет напрягать
Меня ничего не напрягает, я прекрасно понимаю, как и почему сложилась такая ситуация, какая есть, да и все мои девайсы поддерживают Ext4) Но, что бы вы мне ни отвечали, простым пользователям (не мне), которые хотят закинуть фильм на флешку и посмотреть на приставке или перекинуть соседу, на это всё глубоко плевать: им надо чтобы просто работало. А оно не работает. Такие дела.
для конечных пользователей, и форматирование флешек для них «Ext4, XFS, Btrfs» по-прежнему неприемлемо, потому что эту флешку никто не сможет прочитать.
Гм, у меня на флэшке два раздела, один в VFAT, второй в ext3. Не вижу никаких проблем с ext3, все линуксы её читают.
Тот же андроид 6, в чем SD-карту форматирует в режиме расширения основной памяти? Ну 100% там не FAT.
простым пользователям (не мне), которые хотят закинуть фильм на флешку и посмотреть на приставке или перекинуть соседу, на это всё глубоко плевать: им надо чтобы просто работало. А оно не работает.
А пока у соседа винды нет — все работает. А вот если у соседа винда — вот тогда катастрофа.
Как только винда где-то появляется, так всё, приехали. Эту фс не умею, на этой флешке 2 раздела… Винда говно.
С двумя разделами на флэшке у меня никаких проблем. На первом — vFAT, читается на любой винде. На втором ext3 — у меня читается. Но у меня для этого дела драйвер поставлен на винду поставлен. Писать он тоже может, это я уже я сам остерегаюсь.
Начиная с Windows 10 1703 несколько разделов на флешках наконец работают.
А вот если у соседа винда
Ну вообще-то именно с этого и началась данная ветка.
Тот же андроид 6
Чего вы андроид-то приплели, у андроида всё хорошо, я про него ничего не писал и не собираюсь.
все линуксы её читают
А приставки, телевизоры (которые не на андроиде) и соседские винды? Не надо прикидываться, будто проблемы не существует.
Понимаете чем беда…
Когда я 34 года назад начинал работать программистом, пакет дисковод мог ставится только на тот дисковод, где он писался. А на соседний — не стоило, ибо юстировка иная.
Потом это побороли, сделали совместимость между разными устройствами одной машины.
Потом — между разными устройствами однотипных машин.
Теперь мы имеем физическую совместимость между устройствами совсем разных машин. Осталась — логическая совместимость.
В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.
Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
А софт… Ну моя windows XP читает ext3. Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
Когда я 34 года назад начинал работать программистом, пакет дисковод мог ставится только на тот дисковод, где он писался. А на соседний — не стоило, ибо юстировка иная.
Потом это побороли, сделали совместимость между разными устройствами одной машины.
Потом — между разными устройствами однотипных машин.
Теперь мы имеем физическую совместимость между устройствами совсем разных машин. Осталась — логическая совместимость.
В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.
Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
А софт… Ну моя windows XP читает ext3. Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
> Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
Не с целью флуда, однако:
У вас есть драйвер монтирующий флешку или жд в экст4 фс в «мой компьютер», при этом не висящий постоянно в отдельном сервисе?
Не с целью флуда, однако:
У вас есть драйвер монтирующий флешку или жд в экст4 фс в «мой компьютер», при этом не висящий постоянно в отдельном сервисе?
Нету, висит сервис «Ext2 management module». А чем он мешает?
У меня ранее его прибивали антивирусы и всякие «оптимизаторы», приходилось добавлять в исключения, а это уже жирный минус был в использовании.
Это жирный минус "оптимизаторам" и "антивирусам".
UFO just landed and posted this here
Хороший пример. В ядре я такого особенно наелся. Особенно мне нравилось когда разработчик вызывал IoCallDriver, если драйвер который он вызвал, породил исключение, из-за неверной передачи параметров, то решение их было очень простым, обернули в try/except. Вместо того чтобы разобраться в причине. И таких разработок больше чем множество. Кстати спорить с такими разработчиками не возможно. Люди не в состоянии воспринять твою мысль в принципе.
Простите, но блокировка антивирусом абсолютно любого стороннего драйвера — это не нормальное функционирование нормальной программы. И следует помнить, что антивирус для программ, а не программы для антивируса. Секете?
Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
при анализе алгоритмов NAND контроллеров можно сказать, что в основной массе их микропрограммы они не оптимизируются для какой-либо файловой системы. Зависание — это уже признак проблемы устройства.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
Простите, а что именно в них готово, что не приготовлено в USB flash? В SD(SDHC) картах логика работы контроллеров аналогична логике работы контроллеров USB_NAND. Можно рассмотреть примеры различных контроллеров и их нюансы трансляции.
Ну значит такое качество у вас анализа было… :-) Для оптимизации под FAT хватает того, что контролер считает, что часто перезаписываемая область находится в начале диска, а не в его середине или в конце
Эксперимент очень простой. Берете 5-10 неиспользованных флэшек разных моделей. Разбиваете на 2 раздела. Один — большой под FAT, второй в конце, 1-2 гига, под ext3. При попытке растарить на него почти гигабайтный архив — запись зависает примерно в половине случаев.
Потом берете ещё 5-10 флэшек — и пытаетесь их замучать при помощи одного раздела FAT. И все работает отлично.
Можете сами проверить. Но мы покупаем флэшек в два раз больше, чем нам надо. И не всегда хватает. Последний раз брали sundisk на 8 и 16 гигов — они чуть получше, но тоже виснут.
Можете ещё DD сделать с посекторным копированием. Тут уже процентов 75, что флэшка помрет.
Эксперимент очень простой. Берете 5-10 неиспользованных флэшек разных моделей. Разбиваете на 2 раздела. Один — большой под FAT, второй в конце, 1-2 гига, под ext3. При попытке растарить на него почти гигабайтный архив — запись зависает примерно в половине случаев.
Потом берете ещё 5-10 флэшек — и пытаетесь их замучать при помощи одного раздела FAT. И все работает отлично.
Можете сами проверить. Но мы покупаем флэшек в два раз больше, чем нам надо. И не всегда хватает. Последний раз брали sundisk на 8 и 16 гигов — они чуть получше, но тоже виснут.
Можете ещё DD сделать с посекторным копированием. Тут уже процентов 75, что флэшка помрет.
А это не может быть простое завышение объема, как любят делать некоторые?
Можете ещё DD сделать с посекторным копированием. Тут уже процентов 75, что флэшка помрет.Интересно, я тоже это наблюдал на SD-картах и USB-flash. При попытке «почистить» устройство записями нулей в \Device\PhysicalDriveX у меня карточки умирали насовсем. И я решил, что контроллер не может обрабатывать запись в сектора, близкие к началу, и больше так делать не надо.
А это не может быть простое завышение объема, как любят делать некоторые?До умирания устройства были почти полностью забиты данными и никаких проблем с данными не было.
Интересно, я тоже это наблюдал на SD-картах и USB-flash. При попытке «почистить» устройство записями нулей в \Device\PhysicalDriveX у меня карточки умирали насовсем. И я решил, что контроллер не может обрабатывать запись в сектора, близкие к началу, и больше так делать не надо.это были USB flash с изношенной NAND памятью, достаточно износа в области хранения служебных структур, чтобы получить мертвое изделие при первом же сбое в механизме трансляции.
Интересно, что у меня «изношенными» оказывались только что купленые устройства, что SD 1.1, что USB 2.0.
Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)
Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы FAT?
Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)
Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы FAT?
Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы FAT?
Вас не смутило, что любой физический блок может выполнять любую логическую роль? Ничего, что за время жизни USB Flash местоположение FAT таблиц многократно сменится согласно физического адреса, хотя согласно LBA адресации положение будет неизменным?
Интересно, что у меня «изношенными» оказывались только что купленые устройства, что SD 1.1, что USB 2.0.
Претензии по качеству конечного изделия предъявляйте производителю.
Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)
глядя на качество NAND памяти (изначально допустимое количество битовых ошибок и сильно возросшие размеры ЕСС) могу сказать, что я имею в виду некачественные изделия, которые выходят из строя куда раньше, чем обещал производитель.
Меня не смущает, что небо голубое, а трава зеленая. А вас это разве смущает?
Вот и я про о том же. Этот механизм намного лучше работает для начала диска, чем для других областей.
Можно строить много гипотез, почему так происходит. Например, по одной из них, в начале диска каждый сектор транслируется в отдельный физический блок. Понятно, что такой блок будет использоваться неэффективно, зато увеличивается надежность.
Ну тогда назовите те, которые вы считаете «качественными». Проверим, наблюдается ли этот эффект на них.
Ничего, что за время жизни USB Flash местоположение FAT таблиц многократно сменится согласно физического адреса, хотя согласно LBA адресации положение будет неизменным?
Вот и я про о том же. Этот механизм намного лучше работает для начала диска, чем для других областей.
Можно строить много гипотез, почему так происходит. Например, по одной из них, в начале диска каждый сектор транслируется в отдельный физический блок. Понятно, что такой блок будет использоваться неэффективно, зато увеличивается надежность.
я имею в виду некачественные изделия
Ну тогда назовите те, которые вы считаете «качественными». Проверим, наблюдается ли этот эффект на них.
Вот и я про о том же. Этот механизм намного лучше работает для начала диска, чем для других областей.
этому механизму совершенно безразлично, где работать. Все блоки равноправны.
Можно строить много гипотез, почему так происходит. Например, по одной из них, в начале диска каждый сектор транслируется в отдельный физический блок. Понятно, что такой блок будет использоваться неэффективно, зато увеличивается надежность.
можно попросить Вас ознакомиться с хотя бы общими принципами работы NAND контроллеров, а то я затрудняюсь комментировать подобные опусы.
Ну тогда назовите те, которые вы считаете «качественными». Проверим, наблюдается ли этот эффект на них.
Они уже вымирающий вид. Те самые старые USB Flash малой емкости с SLC или хотя бы MLC памятью. Рынку нужны дешевые и емкие изделия, а это TLC, которое с рождения неспособно хранить пользовательские данные без ошибок (живет исключительно за счет емких ЕСС)
этому механизму совершенно безразлично, где работать. Все блоки равноправны.
Ну так докажите это. Экспериментами с современными флэшками или ссылками на даташиты изготовителей. Информации об дизассемблировании одной прошивки десятилетней давности — это не доказательство.
я затрудняюсь комментировать подобные опусы
Тогда я вас ещё сильнее затрудню. S25FL256S — 32 блока по 4 килобайта и 5120 блоков по 64. Это вот был один из кандидатов для нашей платы.
Ну так докажите это.
посмотрите алгоритмы сбора логических образов из дампов полученных из различных USB flash. На том же форуме софтцентра, который доступен публично. Как бы тысячи разных версий NAND контроллеров с некоторыми нюансами работают, но основная суть блочной работы и свободным расположением блоков в рамках логического банка сохраняется.
Экспериментами с современными флэшками или ссылками на даташиты изготовителей.а ничего, что эта информация на данный момент имеет коммерческую ценность?
Тогда я вас ещё сильнее затрудню. S25FL256S — 32 блока по 4 килобайта и 5120 блоков по 64. Это вот был один из кандидатов для нашей платы.
а причем это изделие к NAND памяти? И чем оно должно затруднить?
Ну то есть доказательств у вас нет. У вас есть только ВЕРА в то, что производители не использовали маркетинговые преимущества от увеличения надежности записи в начальные блоки логических адресов.
С другой стороны, у меня — результаты экспериментов. Весьма нестрогие, но показательные.
А любые результаты экспериментов — намного лучше ВЕРЫ.
Мне не важно, что и как там организовано в контроллере. Используются ли блоки разного размера или разные критерии выбора блока для записи или ещё что-то. Но я вижу, что подобный механизм во флэшках есть.
Хотите убедиться — сделайте эксперименты сами.
С другой стороны, у меня — результаты экспериментов. Весьма нестрогие, но показательные.
А любые результаты экспериментов — намного лучше ВЕРЫ.
Мне не важно, что и как там организовано в контроллере. Используются ли блоки разного размера или разные критерии выбора блока для записи или ещё что-то. Но я вижу, что подобный механизм во флэшках есть.
Хотите убедиться — сделайте эксперименты сами.
Ну то есть доказательств у вас нет. У вас есть только ВЕРА в то, что производители не использовали маркетинговые преимущества от увеличения надежности записи в начальные блоки логических адресов.
пока есть только ваше нежелание просмотреть уже указанные источники, чтобы понять основы алгоритмов контроллеров. Речь идет не о вере, а о постоянном анализе различных алгоритмов NAND контроллеров по мере появления их в готовых изделиях.
С другой стороны, у меня — результаты экспериментов. Весьма нестрогие, но показательные.
Один американец тоже проводил эксперименты со спиртовым уровнем доказывая, что земля плоская (думаю найдете в новостях). Пока результаты ваших экспериментов примерно также достоверны, как результаты доказательств того, что земля плоская.
Мне не важно, что и как там организовано в контроллере. Используются ли блоки разного размера или разные критерии выбора блока для записи или ещё что-то.
т. е. вы хотите сказать, что домыслы куда лучше анализа алгоритмов работы устройств?
Но я вижу, что подобный механизм во флэшках есть.
есть только в ваших выводах, которые основаны без учета алгоритма работы самого NAND контроллера.
Хотите убедиться — сделайте эксперименты сами.
Так делаю, но более детальные и с учетом алгоритмов NAND контроллеров.
Ну так давайте ссылку на результаты ваших экспериментов. Какая была методика, что делали. Гляну, могли ли они вообще выявить отличия в алгоритмах.
На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами. Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.
Вот подумайте над ответом на этот вопрос.
На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами. Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.
Вот подумайте над ответом на этот вопрос.
Ну так давайте ссылку на результаты ваших экспериментов. Какая была методика, что делали. Гляну, могли ли они вообще выявить отличия в алгоритмах.Прочтите сначала то, что здесь написано. Приводя примеры с flash памятью научитесь видеть отличия в NOR и NAND, так сказать подготовьтесь к усваиванию материала, а позже выложу на хабр немного материалов по реверс-инжинирингу NAND контроллеров используемых в USB flash.
На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами.
какое преимущество?
Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.
исходя из алгоритмов работы NAND контроллеров на сегодня наиболее удобна файловая система FAT из-за минимальных паразитных нагрузок. Второе удобство совместимость с различными ОС.
Вот подумайте над ответом на этот вопрос.
этот вопрос возникал бы, если бы не фактический анализ структур трансляторов NAND контроллеров, который показывает, что оптимизации идут несколько в другом направлении (снижение паразитных нагрузок при записи малых объемов данных)
Преимущество понятно какое. На всех устройствах хранения прежде всего выходят из строя логические блоки, в которые запись идет чаще всего. Когда мы транслируем логический блок в физический — эта закономерность сохраняется. Чем больше записей в один блок — тем больше шансов, что трансляция в конечном итоге приведет нас в сбойный блок.
Самые часто записываемые блоки на FAT — это область таблицы FAT.
С другой стороны, ошибка записи в тело файла — может быть и не обнаружена потребителем. Или выглядеть как артефакты на одном из кадров видео, что потребитель сочтет сбоем видеозаписи, а не флэшки.
Отсюда и желание на тех устройствах, где FAT составляет 99.9% потребления — оптимизировать характеристики под него.
Такая оптимизация может основываться не только на предоставлении преимуществ начальных логическим блокам, но и на преимуществам часто записываемым блокам вообще. При этом планируемое максимальное количество часто записываемых блоков считается исходя из характеристик FAT.
Так что при анализе вы легко можете не понять, что какая-то оптимизация будет хорошо работать на FAT и плохо на ext3. Тут нужен не просто анализ — а моделирование полученного алгоритма.
Самые часто записываемые блоки на FAT — это область таблицы FAT.
С другой стороны, ошибка записи в тело файла — может быть и не обнаружена потребителем. Или выглядеть как артефакты на одном из кадров видео, что потребитель сочтет сбоем видеозаписи, а не флэшки.
Отсюда и желание на тех устройствах, где FAT составляет 99.9% потребления — оптимизировать характеристики под него.
Такая оптимизация может основываться не только на предоставлении преимуществ начальных логическим блокам, но и на преимуществам часто записываемым блокам вообще. При этом планируемое максимальное количество часто записываемых блоков считается исходя из характеристик FAT.
Так что при анализе вы легко можете не понять, что какая-то оптимизация будет хорошо работать на FAT и плохо на ext3. Тут нужен не просто анализ — а моделирование полученного алгоритма.
Преимущество понятно какое. На всех устройствах хранения прежде всего выходят из строя логические блоки, в которые запись идет чаще всего. Когда мы транслируем логический блок в физический — эта закономерность сохраняется. Чем больше записей в один блок — тем больше шансов, что трансляция в конечном итоге приведет нас в сбойный блок.Вы пока не понимаете основного механизма ротации блоков. Не получится так, что какой-то один блок сильно износится. Изнашиваться будет равномерно группа блоков, так как роли физических блоков будут изменчивыми. Допустим первые три цикла записи FAT таблиц были в нулевой блок, после глядя на показатель счетчика записей при следующей записи этот блок перейдет в первый невключенный в трансляцию в рамках логического банка но с меньшим значением счетчика записей, а нулевой будет исключен из трансляции. Таким образом изменяемые данные будут постоянно менять свое физическое положение, хотя логически они будут оставаться на прежнем месте. И механизм этот в основе работы практически всех NAND контроллеров (с теми или иными нюансами).
Самые часто записываемые блоки на FAT — это область таблицы FAT.
это никто не оспаривает, но в итоге это не отражается на непосредственно износе каких-то конкретных блоков. Происходит равномерный износ группы блоков и чем меньше статичной информации лежащей на накопителе без изменений, тем эффективнее работает алгоритм выравнивания износа.
Отсюда и желание на тех устройствах, где FAT составляет 99.9% потребления — оптимизировать характеристики под него.
производители занимаются оптимизацией алгоритмов мелких записей, чтобы снижать паразитные нагрузки. И алгоритмам все равно FAT будет или NTFS или Ext. Они просто отработают в силу своих возможностей. Естественно самая меньшая паразитная нагрузка будет в случае FAT из-за организации самой файловой системы.
Такая оптимизация может основываться не только на предоставлении преимуществ начальных логическим блокам, но и на преимуществам часто записываемым блокам вообще. При этом планируемое максимальное количество часто записываемых блоков считается исходя из характеристик FAT.
Так что при анализе вы легко можете не понять, что какая-то оптимизация будет хорошо работать на FAT и плохо на ext3. Тут нужен не просто анализ — а моделирование полученного алгоритма.
Вы не уразумев основной логики работы NAND контроллеров, сейчас описываете очень далекие от эффективных по отношению к NAND памяти приемы.
А эта волшебная ротация, на основе чего вообще происходит? Как, после первой записи во все блоки, контроллер отличает занятые блоки от свободных? Через USB ведь TRIM не работает.
А эта волшебная ротация, на основе чего вообще происходит? Как, после первой записи во все блоки, контроллер отличает занятые блоки от свободных? Через USB ведь TRIM не работает.
микрокод USB-NAND контроллера имеет в распоряжении транслятор, где описываются задействованные блоки в рамках каждого логического банка. При каждой (или после нескольких) перезаписи блока, он исключается из трансляции и переводится в резервные, а его роль начинает выполнять вошедший в трансляцию.
сегодня или в понедельник выложу на хабр описание алгоритма работы одного из USB NAND контроллеров (немного скриншотов приготовлю для лучшей усвояемости материала). В ЕСС, глубины транслятора погружаться не буду, чтобы не пугать читателей. Полагаю, тогда многие вопросы отпадут.
Происходит равномерный износ группы блоков и чем меньше статичной информации лежащей на накопителе без изменений, тем эффективнее работает алгоритм выравнивания износа.
Гм, пишем на флэшку до полного заполнения, потом удаляем все файлы или форматируем флэшку. Что будет? «Статической информации» — ноль. Будет ли при этом алгоритм выравнивания износа работать эффективно?
Если будет — это означает, что флэшка понимает удаление файлов, то есть заточена под файловую систему. А затачивать её имеет смысл только под FAT. Если не будет — значит вы недопонимаете тонкости или некорректно формулируете определения.
FAT обладает следующими особенностями:
- Наиболее часто перезаписываемая область (таблица FAT) находится в начале диска
- Заполнение диска идет с начальных секторов. Более того, Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.
- Создание файла обычно идет в 4 приема: таблица FAT, каталог, сам файл, перезапись длины в каталоге.
- Области каталогов и данных файла обычно находятся в разных физических блоках флэш, то есть удалены по логическим адресам.
Все это не так для ext2.
- Часто перезаписываемые области (bitmap и inode) в середине диска
- Заполнение идет равномерно по всему диску. То есть с точки зрения самой флэшки диск быстро становится заполнен на 100%.
- Создание файла идет в 4 приема bitmap, inode, каталог, тело файла.
- При этом во многих случаях bitmap и inode попадают в один физический блок флэшки. а каталог и тело файла — в другой физический блок. Таким образом, кэширование на 1 блок — очень выгодно для ext2.
Учетом любой из этих особенностей можно сделать оптимизацию под ту или иную файловую систему.
Например, можно считать все логические блоки, в которых никогда не было записи — свободными. И включить в ротацию соответствующие физические блоки. И это будет огромное преимущество именно для FAT.
А можно вообще сделать границу между свободными и несвободными блоками по записанному логическому блоку с наибольшим адресом. И это будет ещё большее преимущество именно для FAT.
Грубо говоря, если файлы занимают 10% диска — на FAT можно легко включить в ротацию 90% диска. А вот на ext2 даже 5% занятого места ограничивают ротацию считанными резервными блоками.
И это помимо тех оптимизаций, о которых я писал ранее.
Гм, пишем на флэшку до полного заполнения, потом удаляем все файлы или форматируем флэшку. Что будет? «Статической информации» — ноль. Будет ли при этом алгоритм выравнивания износа работать эффективно?
для подавляющего большинства USB flash это будет означать, что придется переписать лишь группу блоков с метаданными файловой системы. По мере записи новой информации. Но по мере записи в пустые блоки, которые согласно транслятора заняты, ротация будет происходить. Пусть не самый эффективный алгоритм, но достаточно неплохо отработает в случае удаления, форматирования, при записи новых данных.
Если будет — это означает, что флэшка понимает удаление файлов, то есть заточена под файловую систему. А затачивать её имеет смысл только под FAT. Если не будет — значит вы недопонимаете тонкости или некорректно формулируете определения.
USB Flash не понимает нюансов файловой системы за исключением некоторых очень древних «проб пера» авторов фирмварей, которые давно показали неэффективность.
FAT обладает следующими особенностями:
Наиболее часто перезаписываемая область (таблица FAT) находится в начале диска
Заполнение диска идет с начальных секторов. Более того, Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.
справедливо для логического пространства. В физическом все будет выглядеть по другому. Опять же пример в статье, что произойдет при перезаписи блока.
Грубо говоря, если файлы занимают 10% диска — на FAT можно легко включить в ротацию 90% диска. А вот на ext2 даже 5% занятого места ограничивают ротацию считанными резервными блоками.
тут вы лишь декларируете, что не понимаете сути алгоритма NAND контроллера. Ротация будет осуществляться в рамках логического банка (количество банков — это уже нюанс работы того или иного NAND контроллера). И неважно речь пойдет о метаданных EXT или FAT. Разница в том, что паразитных нагрузок в случае EXT будет больше, чем в случае FAT, так как для перезаписи крошечных объемов придется переписывать целиком крупные блоки.
И это помимо тех оптимизаций, о которых я писал ранее.
пока что описание ваших оптимизаций, лишь плод вашего воображения, а не фактические реализации в микропрограммах.
Разница в том, что паразитных нагрузок в случае EXT будет больше, чем в случае FAT
Почему? Потому что ext2 кэшируется и несколько обновлений одного сектора сливаются в одно? Потому что 4 записи для создания короткого файла на FAT вам кажутся сильно меньше 4 записей для той же операции на ext2? Или потому, что флэшка оптимизирована для FAT?
Вот и подумайте, почему 4 для ext2 вам кажутся сильно больше, чем те же 4 для FAT.
> Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.
Интересно, это во всех реализациях FAT так?
Логично было для разработчиков драйверов ФС в зависимости от конкретных требований добавить в этот алгоритм одну из двух или сразу две оптимизации (первую по крайней мере во времена царствования старых жестких дисков). Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.
Во-вторых, выделять место в ранее не использованном пространстве, чтобы повысить вероятность восстановления данных после удаления (необходимые данные о ранее занятых, а после освобожденных кластерах можно хранить «внутри» драйвера ФС).
> Области каталогов и данных файла обычно находятся в разных физических блоках флэш, то есть удалены по логическим адресам.
> Все это не так для ext2.
> а каталог и тело файла — в другой физический блок.
Почему для FAT и ext2 в этом случае будет разница?
Могу ошибаться, но в обоих случаях каталог — это тоже файл (за исключением корневого каталога FAT). И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
Интересно, это во всех реализациях FAT так?
Логично было для разработчиков драйверов ФС в зависимости от конкретных требований добавить в этот алгоритм одну из двух или сразу две оптимизации (первую по крайней мере во времена царствования старых жестких дисков). Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.
Во-вторых, выделять место в ранее не использованном пространстве, чтобы повысить вероятность восстановления данных после удаления (необходимые данные о ранее занятых, а после освобожденных кластерах можно хранить «внутри» драйвера ФС).
> Области каталогов и данных файла обычно находятся в разных физических блоках флэш, то есть удалены по логическим адресам.
> Все это не так для ext2.
> а каталог и тело файла — в другой физический блок.
Почему для FAT и ext2 в этом случае будет разница?
Могу ошибаться, но в обоих случаях каталог — это тоже файл (за исключением корневого каталога FAT). И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.
Для этого на этапе создания файла ОС должна хотя бы примерно понимать его размер. А обычная схема создания файла этого не предусматривает. open/write/close, и только на этапе close, по положению файлового указателя определяется размер файла. Да, есть SetFilePointer и SetEndOfFile в WinAPI, в Си (POSIX) можно сделать ftruncate, но… вы используете эти вызовы в своих программах? Вот и другие не используют. Ну разве что в программах копирования или разархивирования файлов.
Так что самый частый случай — в момент создания файла длина неизвестна, а известна она становится лишь при закрытии файла.
Так что ваша оптимизация присутствует в ОС, но работает лишь в тех редких случаях, когда длина известна заранее — то есть в основном при копировании или разархивировании файла.
Во-вторых, выделять место в ранее не использованном пространстве,
В FAT я такого не видел. Наоборот, стараются предотвратить разрастание занятой области. Одна из причин — на внешних дорожках старых дисков плотность записи меньше, чем на внутренних (число секторов фиксировано, физическая длина внешних дорожек больше). То есть запись надежнее.
Почему для FAT и ext2 в этом случае будет разница?
Цитата из вики
Ядро Linux, используя число индексных дескрипторов, содержащих каталоги, пытается равномерно распределить inode каталогов по группам, а inode файлов старается по возможности переместить в группу с родительским каталогом
Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру. А операция — «прочли каталог, потом читаем файл» — это частая операция и нуждается в оптимизации. Размещение inode в группе с каталогом практически гарантирует, что данные файла будут в той же группе (ну пока файл не слишком разросся).
И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
Для 2хмеговый физических блоков флэш и файлов меньше 512 байт — вероятность попасть в один и тот же физический блок достаточно велика.
Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру.
Как она это делает, если геометрия накопителя — неизвестна?
Без перфекционизма, но делает. Исходя из того, что сектора с близкими номерами — требуют меньше времени на перемещение головок, чем сектора с очень дальними номерами.
Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей. Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась целью
Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей. Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась целью
Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась цельюсовпадала для MFM/RLL накопителей. А 1993 год — это 7 лет прошло с момента появления IDE. В которых уже CHS параметры были виртуальными.
Вы путаете метод записи битов на диск (FM/MFM/RLL) с методом связи диска с компьютером (ST-506/ESDI/SCSI/IDE (он же АТА)).
Ну это как-то несерьезно — путать мягкое с кислым. Через IDE работали и MFM диски размерами 20-40 мегабайт.
Проблемы встали, когда размеры начали выходить за пределы, допустимые для IDE. Вот тогда LBA (ATA-1) запоздал и появились варианты с подменой геометрии.
Но большинство дисков 1993 года — вполне жили в CHS с натуральной геометрией. Насколько мне помнится, тогда самыми популярными были 80мегабайтные диски, а им трансляция ещё не нужна была.
Ну это как-то несерьезно — путать мягкое с кислым. Через IDE работали и MFM диски размерами 20-40 мегабайт.
Проблемы встали, когда размеры начали выходить за пределы, допустимые для IDE. Вот тогда LBA (ATA-1) запоздал и появились варианты с подменой геометрии.
Но большинство дисков 1993 года — вполне жили в CHS с натуральной геометрией. Насколько мне помнится, тогда самыми популярными были 80мегабайтные диски, а им трансляция ещё не нужна была.
Вы путаете метод записи битов на диск (FM/MFM/RLL) с методом связи диска с компьютером (ST-506/ESDI/SCSI/IDE (он же АТА)).
ключевой момент. старые диски, не имели набортного контроллера. Всем сервоприводом управлял контроллер. И вот тогда речь шла о реальной геометрии. Почитайте про ключевые изменения в архитектуре с появлением IDE. IDE контроллер — хост контроллер и обмен данным с накопителем по протоколам описанным в АТА стандарте.
Ну это как-то несерьезно — путать мягкое с кислым. Через IDE работали и MFM диски размерами 20-40 мегабайт.
20-40мегабайт это уже ARLL (много разных видов) диски. Методы кодирования данных более совершенные (если уже про методы записи).
Но большинство дисков 1993 года — вполне жили в CHS с натуральной геометрией. Насколько мне помнится, тогда самыми популярными были 80мегабайтные диски, а им трансляция ещё не нужна была.Неправда.
Conner CP3046F с виртуальной CHS адресацией (40Мб). При виртуальных CHS C-977,H-5, S-17. В паспорте висит реальная геометрия С-1053 H-2 S-40. Вскрытие покажет 1 пластину и две головки. И так почти все HDD тех времен и тех емкостей в 3,5" исполнении.
Говоря о коннере, можно сказать, что для тех времен весьма интересная микропрограмма с развитой терминальной системой.
Насколько я помню, 3.5 — это была экзотика для 1993 года. Большинство винчестеров было 5.25.
см, мой пост выше, 1053 дорожки — это как раз тот случай, когда физическая геометрия не лезла в CHS.
P.S. Вы, похоже, путаете год разработки модели с годом её популярности на рынке.
см, мой пост выше, 1053 дорожки — это как раз тот случай, когда физическая геометрия не лезла в CHS.
P.S. Вы, похоже, путаете год разработки модели с годом её популярности на рынке.
Насколько я помню, 3.5 — это была экзотика для 1993 года. Большинство винчестеров было 5.25.обратите внимание, что при одинаковых технологиях тех времен, на 5,25 диск можно было нанести еще больше треков, ибо реально площадь выше. 3,5" показательно, что даже на более модный 3,5" форм фактор было неуместно говорить о реальной CHS адресации.
P.S. Вы, похоже, путаете год разработки модели с годом её популярности на рынке.Похоже, что Вы были уверены, в том, что CHS параметры были настоящими, а производители несколько раньше их сделали виртуальными.
Суть в том, что 3.5 — это были дорогие современные винчестеры для ноутбуков, а 5.25 — делались для массового сегмента и по более старым технологиям. Кроме того, 5.25 бывали и высоты 2U. Представляете, сколько блинов там размещалось? А вот 3.5 — это 1/2U или 1/4U. То есть 1-2 блина максимум.
Суть в том, что 3.5 — это были дорогие современные винчестеры для ноутбуков, а 5.25 — делались для массового сегмента и по более старым технологиям. Кроме того, 5.25 бывали и высоты 2U. Представляете, сколько блинов там размещалось? А вот 3.5 — это 1/2U или 1/4U. То есть 1-2 блина максимум.
У меня в донорской базе можно найти много старых дисков и я многих их них могу пощупать вживую. Естественно представляю и как их реальную геометрию, так и некоторые особенности микропрограмм.
В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.
Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
Началась беседа с Вами после подобного утверждения. Которое некорректно. И на попытку возражения Вам, вы требовали доказательств. И вам были показаны некоторые материалы по реверс-инжинирингу одного из NAND контроллеров и даны комментарии.
Ну так докажите это.
Давай предложим Вам сделать тоже самое? Вы расскажете на чем основаны Ваши выводы касательно оптимизаций и почему SD карты уже готовы, а USB flash нет.
Естественно представляю и как их реальную геометрию, так и некоторые особенности микропрограмм.
Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.
Вы расскажете на чем основаны Ваши выводы касательно оптимизаций и почему SD карты уже готовы, а USB flash нет.
Про оптимизации много раз уже говорил, а выводы основаны на опыте,
Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.
Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.скорее вы притянули за уши трактовку, как некое признание.
Про оптимизации много раз уже говорил, а выводы основаны на опыте,то есть вы из-за того, что у вас зависли некоторые USB flash без каких-либо предпосылок сделали выводы, что виной тому оптимизации под FAT? А как же анализ принципов работы устройства, чтобы доказать, что виной тому оптимизации для FAT и что это не просто тыканье пальцем в небо?
Также пролейте свет на то, что ж такого в SD картах, что они по вашему мнению готовы к разным файловым системам, а USB flash нет? Для более интересного вашего объяснения уточню, что алгоритмы работы с NAND памятью идентичные и у тех и у других накопителей в зависимости от производителя.
Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.дата выпуска может подсказать.
Были и восьмидесятки с ST-506 по двум шлейфам, с MFM. У меня была такая — на 2 слота 5.25.
Без перфекционизма, но делает. Исходя из того, что сектора с близкими номерами — требуют меньше времени на перемещение головок, чем сектора с очень дальними номерами.
А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.
Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей.
Вот именно. Там может быть и 16 блинов с виртуальным преобразованием LBA в CHS, которое совсем не отвечает реальному положению дел. И трюк вида «быстрее переключиться на другую головку в следующем секторе, пока блин вращается, interleave вот это все» уже не будет однозначно работать.
А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.Это вы уже из пальца какую-то фигню вытаскиваете.
Да, могут. Иногда (чтобы скрыть «плохие блоки») какой-нибудь сектор могли и «за можай», на самый край диска. Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?
А она реально очень сильно ускоряла работу с дисков до появления SmartDrv.
Это вы уже из пальца какую-то фигню вытаскиваете.
Что CHS — не всегда реальны? Нет, это факт. Что соседние блоки могут не быть соседними физически? Тоже факт. В среднем — да, должны быть рядом.
Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?
Все верно, так же как read ahead.
Но при всем при этом есть определенный алгоритм трансляции логического номера блока в CHS, (на уровне, например, BIOS или DOS, если уж вспоминать старину). И это будет трансляция в виртуальный CHS.
на уровне, например, BIOS или DOS, если уж вспоминать старинуBIOS и DOS никогда ничего не транслировали. После появления IDE этим стал винчестер заниматься — но он, разумеется учитывал то, что BIOS и DOS считали что CHS — это таки «настоящие» CHS…
Номера логические. Но понятно, что сектора 1700 и 1800 ближе к друг другу, чем сектора 700 и 95000. Так что без перфекционизма — но оптимизируется.
Номера логические. Но понятно, что сектора 1700 и 1800 ближе к друг другу, чем сектора 700 и 95000. Так что без перфекционизма — но оптимизируется.
неудачный пример. С учетом зонного распределения с вашими цифрами может быть меньшим маршрут от 700 до 95000, нежели от 1700 до 1800.
Лучше показать пример: очередь на чтение из трех секторов 100, 800 000 000, 100 000 000 будет исполнена, как 100, 100 000 000, 800 000 000. В таком примере достаточно очевидно преимущество в операциях позиционирования. В случае мелких смещений смысл в сортировке есть, так как эффективно отработает упреждающее чтение (look ahead)
пример анализа одного из алгоритмов USB NAND контроллеров с картинками. По факту их проводилось великое множество (уж больно много разных NAND контроллеров). Естественно хватает отличий и ухищрений. Но нет ничего близко похожего на ваши утверждения.
Ну если это называть анализом… Проанализирован только нижний слой алгоритма. Верхний вы даже не пытались анализировать. Чуть позже прямо там напишу вопросы, на которые вы не ответили.
Ну если это называть анализом… Проанализирован только нижний слой алгоритма. Верхний вы даже не пытались анализировать. Чуть позже прямо там напишу вопросы, на которые вы не ответили.
А вы не сочиняйте алгоритмов, которых нет. Сначала найдите признаки их существования, где-то кроме как у Вас в фантазиях. Причины того, что USB flash у вас умирали с использованием Ext совсем в другом. Разберите хотя бы структуры хоть одной из фирмварей USB_NAND контроллера, проанализируйте хоть один код, чтобы понять задачи MCU, что в подавляющем случае они не занимаются анализом данных. У них и так хватает нагрузки.
Здесь верно лишь то, что для оптимизации под FAT не нужен анализ данных. Вполне хватает анализа адреса записываемого сектора.
Здесь верно лишь то, что для оптимизации под FAT не нужен анализ данных. Вполне хватает анализа адреса записываемого сектора.
Правда? А ничего, что размер таблиц FAT обратно пропорционален размеру кластера?
Возьмем абстрактный раздел 8GiB кластер 4KiB. Количество записей в таблице описывающей пространство будет равным 8 589 934 592/4 096=2 097 152/. Размер одной записи 4 байта. т.е. в сектор помещается 512/4=128 записей. 2 097 152/128=16 384 секторов или 8MiB размер одной копии таблицы FAT32. Две копии соответственно 16MiB.
кластер 8КiB, обе копии таблиц 8MiB
кластер 16KiB, обе копии таблиц 4MiB
А теперь вернемся к NAND контроллеру, ему чтобы оптимизировать каким-то образом запись необходимо знать размер таблиц. Как минимум должен быть алгоритм поиска boot сектора и разбор параметров из него, для создания схемы оптимизации.
Нужны ли лишние заботы микропрограмме дохлого NAND контроллера? Разбор огромного количества разных контроллеров показывает, что нет. Оптимизации разработчиков идут несколько в другом направлении, что сказывается на уменьшении паразитных нагрузок для записи мелких блоков. Подобные оптимизации снижают нагрузку как при записи метаданных файловой системы, так и при записи небольших файлов.
А ничего. В начале у нас кроме FAT ещё и корневой каталог. И просто каталоги. В итоге, если мы при ротации для блоков ниже 32 MiB будем выбирать наименее изношенный физический блок, а для остальных — более изношенный физический блок, то изношенные физические блоки у нас осядут в неизменяемых данных.
Ещё полезная оптимизация — физические блоки, в которых вообще никогда не было записи, держать в списке резервных. Особенно если в качестве номера банка взять младьшие биты адреса блока.
Что за тайная оптимизация? Объединение нескольких логических записей в близкие сектора в одну физическую запись?
Ещё полезная оптимизация — физические блоки, в которых вообще никогда не было записи, держать в списке резервных. Особенно если в качестве номера банка взять младьшие биты адреса блока.
Оптимизации разработчиков идут несколько в другом направлении, что сказывается на уменьшении паразитных нагрузок для записи мелких блоков.
Что за тайная оптимизация? Объединение нескольких логических записей в близкие сектора в одну физическую запись?
Что за тайная оптимизация? Объединение нескольких логических записей в близкие сектора в одну физическую запись?
нет. Введение понятий блок-апдейтов. Блоков, в которых хранятся лишь группы страниц для разных блоков, которые в трансляции частично заместят содержимое оригинального блока. Снижает паразитные нагрузки при записи.
Ещё полезная оптимизация — физические блоки, в которых вообще никогда не было записи, держать в списке резервных. Особенно если в качестве номера банка взять младьшие биты адреса блока.
Что-то вы про «номера банка» несуразное написали. Попробуйте переписать.
А ничего. В начале у нас кроме FAT ещё и корневой каталог. И просто каталоги. В итоге, если мы при ротации для блоков ниже 32 MiB будем выбирать наименее изношенный физический блок, а для остальных — более изношенный физический блок, то изношенные физические блоки у нас осядут в неизменяемых данных.
Счетчики записей для блоков (там где они есть и где известны) как бы не намекают на подобный алгоритм действий. Насчет «изношенные физические блоки осядут в неизменяемых данных» не получится. Например неизменяемые данные записаны на новую USB flash и до конца жизни накопителя никто их не перезаписывает. В итоге имеем неизменяемые данные в совершенно неизношенных блоках.
Про номера банков не поняли? А все просто. 0,4, 8, 12 логический блок — нулевой банк, 1, 5, 9, 13 — первый, 2, 6, 10, 14 — второй, 3, 7, 11, 15 — третий. А не так, что первый 2 мегабайта — все в нулевой банк. И это тоже оптимизация под FAT. она дает равномерное заполнение банков для заполненной не до конца флэшки.
Если этой оптимизации нет, то при заполненной на 20% флэшке у нас на FAT будет использоваться только нулевой банк. А на ext2 — заполнение диска более равномерное, так что такая оптимизация важна прежде всего для FAT.
Помнится, в служебной информации были не опознанные вами биты. Не хранится ли там число потребовавшихся ECC-коррекций? И не является ли оно не менее важным, чем счетчик записей?
Любые процессы с флэшкой надо анализировать как вероятностные. Вы приводите частный случай. А для любого алгоритма есть частные случаи, когда все плохо. Для того делается моделирование, чтобы проверить, как алгоритм ведет себя на большом массиве типичных случаев.
Ну давайте попробуем подумать???
Ну скажем есть тысяча файлов по 2 мегабайта в каждом (128 кластеров). Пишутся они обычным образом: открыли, записали данные и закрыли. Это означает, что на каждый файл было 128 записей в FAT, 2 записи в каталог и 1 запись данных. Так что после первых 10 файлов — уже сильно выгодно изношенные блоки выдавать на «вечное хранение» под данные файла.
Если этой оптимизации нет, то при заполненной на 20% флэшке у нас на FAT будет использоваться только нулевой банк. А на ext2 — заполнение диска более равномерное, так что такая оптимизация важна прежде всего для FAT.
Счетчики записей для блоков (там где они есть и где известны) как бы не намекают на подобный алгоритм действий
Помнится, в служебной информации были не опознанные вами биты. Не хранится ли там число потребовавшихся ECC-коррекций? И не является ли оно не менее важным, чем счетчик записей?
Насчет «изношенные физические блоки осядут в неизменяемых данных» не получится.
Любые процессы с флэшкой надо анализировать как вероятностные. Вы приводите частный случай. А для любого алгоритма есть частные случаи, когда все плохо. Для того делается моделирование, чтобы проверить, как алгоритм ведет себя на большом массиве типичных случаев.
Например неизменяемые данные записаны на новую USB flash и до конца жизни накопителя никто их не перезаписывает. В итоге имеем неизменяемые данные в совершенно неизношенных блоках.
Ну давайте попробуем подумать???
Ну скажем есть тысяча файлов по 2 мегабайта в каждом (128 кластеров). Пишутся они обычным образом: открыли, записали данные и закрыли. Это означает, что на каждый файл было 128 записей в FAT, 2 записи в каталог и 1 запись данных. Так что после первых 10 файлов — уже сильно выгодно изношенные блоки выдавать на «вечное хранение» под данные файла.
Про номера банков не поняли? А все просто. 0,4, 8, 12 логический блок — нулевой банк, 1, 5, 9, 13 — первый, 2, 6, 10, 14 — второй, 3, 7, 11, 15 — третий. А не так, что первый 2 мегабайта — все в нулевой банк. И это тоже оптимизация под FAT. она дает равномерное заполнение банков для заполненной не до конца флэшки.
говоря о физических банках, то показан разброс по микросхемам.
Говоря о логических банках
0x0-0x3C3*0x200000=именно столько логического пространства реализует нулевой банк. 0 блок из 1 банка — это уже 0x3C4 блок в логическом пространстве. Необходимость организации в банки — экономия на размере маркера номера блока (маркер с номером в служебке блока, дублирующая информация из транслятора и существует далеко не во всех служебках). В случае, если в данном SK6211 использовать FAT, то таблицы всегда будут находиться только в границах 0 банка. (И по факту находятся там).
Если этой оптимизации нет, то при заполненной на 20% флэшке у нас на FAT будет использоваться только нулевой банк. А на ext2 — заполнение диска более равномерное, так что такая оптимизация важна прежде всего для FAT.
как уже написано он и есть в нулевом логическом банке в случае SK6211, но есть контроллеры, для которых все пространство будет как один логический банк.
Помнится, в служебной информации были не опознанные вами биты. Не хранится ли там число потребовавшихся ECC-коррекций? И не является ли оно не менее важным, чем счетчик записей?
понимаете при перемещении данных в другой блок (а смена позиции логического блока происходит при перезаписи даже части информации), а старый блок исключается и очищается (полностью все биты установлены 0xFF) т.е. информации о качества чтения для этого физического блока не остается и смысла ее тащить в другой блок нет. Не исключено, что можно ввести счетчики количества коррекций согласно ЕСС, но тупиковое направление в силу того, что в современной TLC памяти коррекции будут чуть ли не в каждой странице блока (только что выпущенной памяти).
Любые процессы с флэшкой надо анализировать как вероятностные. Вы приводите частный случай. А для любого алгоритма есть частные случаи, когда все плохо. Для того делается моделирование, чтобы проверить, как алгоритм ведет себя на большом массиве типичных случаев.в силу специфики деятельности я знакомлюсь с большим количеством разных контроллеров.Привел пример очень популярного алгоритма, который с незначительными нюансами можно видеть в массе других контроллеров.
Ну скажем есть тысяча файлов по 2 мегабайта в каждом (128 кластеров). Пишутся они обычным образом: открыли, записали данные и закрыли. Это означает, что на каждый файл было 128 записей в FAT, 2 записи в каталог и 1 запись данных. Так что после первых 10 файлов — уже сильно выгодно изношенные блоки выдавать на «вечное хранение» под данные файла.
и зачем? Если есть еще много блоков, в которые не было записей. А также откуда контроллеру узнать, что данные будут лежать мертвы грузом, а не будут активно перезаписываться?
Необходимость организации в банки — экономия на размере маркера номера блока
А с этим никто не спорит. Просто эффективней из LBF-адреса сектора под адрес банка выделить младшие биты. В минусах будет одинаковое количество блоков в банке.
тупиковое направление в силу того, что в современной TLC памяти коррекции будут чуть ли не в каждой странице блока
Тем не менее, по каким-то критериям блоки отправляются в список bad-блоков. И скорее всего эти критерии количественные, то есть позволяют выделить надежные и слабые блоки.
старый блок исключается и очищается (полностью все биты установлены 0xFF) т.е. информации о качества чтения для этого физического блока не остается
Её можно хранить в памяти контроллера. Правда встает вопрос о хранении между включениями — скорее всего в контролере нету своей флэш-памяти.
В целом аргумент про полное стирание — сильный.
откуда контроллеру узнать, что данные будут лежать мертвы грузом, а не будут активно перезаписываться?
А тут есть хорошая презумпция. Таблицы FAT — перезаписываться будут, остальные данные — скорее всего нет. То есть можем считать что первые логические 32 мегабайта — перезаписываются часто, остальное — редко. И в 99% случаев — будем правы.
и зачем? Если есть еще много блоков, в которые не было записей.
А вот это уже особенность ext2. У меня такое впечатление, что после записи 5-10 процентов на ext2 уже записаны все блоки. Дело в том, что ext2 борется с фрагментацией файлов путем рассредоточения их по диску. Плюс ещё старается разместить файлы поближе к каталогам. А каталогов — порядка тысячи. В итоге после записи каталоговой структуры — уже можно считать что большинство блоков записано. Это не FAT, где при создании каталоговой структуры все каталоги попадут лишь в несколько логических блоков.
А тут есть хорошая презумпция. Таблицы FAT — перезаписываться будут, остальные данные — скорее всего нет. То есть можем считать что первые логические 32 мегабайта — перезаписываются часто, остальное — редко. И в 99% случаев — будем правы.
нередкая ситуация: работа с файлом на USB flash. Какой-нибудь студент делающий реферат, один файл пересохранит многократно. При том что редакция будет незначительна и размер в кластерах прежний и положение в логическом пространстве прежнее. И таких ситуаций множество, когда надо думать не только о FAT таблицах, в связи с чем направления по оптимизации записи именно FAT таблиц как-то иначе, чем иные данные не получают широкого распространения.
А вот это уже особенность ext2. У меня такое впечатление, что после записи 5-10 процентов на ext2 уже записаны все блоки. Дело в том, что ext2 борется с фрагментацией файлов путем рассредоточения их по диску. Плюс ещё старается разместить файлы поближе к каталогам. А каталогов — порядка тысячи. В итоге после записи каталоговой структуры — уже можно считать что большинство блоков записано. Это не FAT, где при создании каталоговой структуры все каталоги попадут лишь в несколько логических блоков.итог: паразитная нагрузка в случае Ext выше
Тем не менее, по каким-то критериям блоки отправляются в список bad-блоков. И скорее всего эти критерии количественные, то есть позволяют выделить надежные и слабые блоки.как правило они отправляются технологическим ПО. Исключить блок из трансляции можно по многим критерями. Например по количеству попыток чтения с использованием Read Retry, после успешного прочтения, но с долгими мучениями переписать его в другой блок. Но есть ли смысл закладывания этих алгоритмов в обычные USB flash — большой вопрос.
Например у современных NAND микросхем, есть возможность в каждой плоскости по страницам исключать проблемные столбцы (Bad Column) и формировать список проблемных столбцов, где наиболее вероятно возникновение ошибок. Но производители не тестируют все микросхемы, часто информация об исключенных столбцах записанная в микросхемы ничего не имеет общего с реальными проблемными местами.
Технология производства выглядит как быстро, дешево и лишь бы кое-как работало.
Какой-нибудь студент делающий реферат, один файл пересохранит многократно. При том что редакция будет незначительна и размер в кластерах прежний и положение в логическом пространстве прежнее.
Мда… Знаете с времен редактора TED для RSX-11М много воды утекло. Никто не перезаписывает уже лежащий на диске файл. Делает так:
- Создали файл с новым, временным именем. Для Word имя этого файла начинается с тильды.
- Записали данные в него.
- Существующий файл переименовали в .bak
- Новому файл дали имя старого файла.
- Удалили .bak
Последние лет 30 — это основная технология, все остальные варианты — приводят к потере файла из-за сбоя во время записи.
итог: паразитная нагрузка в случае Ext выше
УВЫ. Итог —
Введение понятий блок-апдейтов. Блоков, в которых хранятся лишь группы страниц для разных блоков, которые в трансляции частично заместят содержимое оригинального блока.
Хорошая оптимизация, но сложная. Ну не поверю, что объединение двух логических передач данных в одну физическую запись не сделали раньше.
Хорошая оптимизация, но сложная. Ну не поверю, что объединение двух логических передач данных в одну физическую запись не сделали раньше.
подобное обычно на уровне драйвера ОС. Как например в жестких дисках уже много лет как введено понятие AHCI контроллера, который сортирует очередь команд для оптимизации перемещений БМГ. Буферизацию на запись с оптимизации записей для сменных устройствах обычно не используют. В силу того, что от пользователя можно ждать постоянных подвохов связанных с извлечением накопителя в неподходящий момент. USB NAND контроллер просто обслуживает R/W операции идущие поверх USB PHY и тут уже вопрос как обрабатываются команды. Учитывая, что в некоторых USB flash используются те же контроллеры что и в некоторых бюджетных SSD, то можно предполагать наличие классических оптимизаций. Но в случае простых контроллеров, так оптимизаций обычно нет.
Драйвер ОС не знает размера физического блока и ориентируется на размер кластера.
Тот же linux — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет. С другой стороны, не так важно, выдернем ли мы флэшку во время записи или во время буферизациии длиной в 1 микросекунду. Более 50 миллисекунд — буферизацию делать не стоит. А до 50 мс — это «вытащил ровно во время записи».
Ну я рад, что в каких-то вещах мы начинаем сходится.
Тот же linux — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет. С другой стороны, не так важно, выдернем ли мы флэшку во время записи или во время буферизациии длиной в 1 микросекунду. Более 50 миллисекунд — буферизацию делать не стоит. А до 50 мс — это «вытащил ровно во время записи».
можно предполагать наличие классических оптимизаций
Ну я рад, что в каких-то вещах мы начинаем сходится.
Тот же linux — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет.
самый опасный момент. Выдернуть USB flash в момент, когда будет происходить запись оверлея трансляции и мгновенный трупик. Конечно на не факт, что на сотню выдергиваний удастся поймать момент, но тем не менее анализируя поток мертвых накопителей вижу немало случаев, когда это стало причиной смерти накопителя.
Драйвер ОС не знает размера физического блока и ориентируется на размер кластера.тем не менее две последовательные записи он потенциально может объединить в одну, а дальше пусть NAND контроллер смотрит, пролезет все в один блок или нет.
UFO just landed and posted this here
Вот по личному опыту больше трупов я видел после стандартного извлечения с помощью «отключить устройство» в винде.При изношенной памяти и сбоях при записи уже неважно как будет извлечен накопитель из USB порта.
Не можете прокомментировать?
UFO just landed and posted this here
Индикаторы скорее всего показывают передачу данных, а не сам процесс записи. При штатном отключении записывается FSinfo. Отгадка скорее всего в том, что при выдергивании вы ждете пару секунд после окончания индикации, а при штатном завершении — ориентируетесь на клик мышкой, и в итоге попадаете как раз на операцию записи. Выжидайте пару секунд — и все будет нормально.
Спасибо за красивый эффект, сам не знал, пока копаться не начал.
Спасибо за красивый эффект, сам не знал, пока копаться не начал.
Оверлей трансляции — это что за зверь?
Потенциально может, но зачастую путем потери во времени передачи данных. Например, при двух записях в FAT, вам придется передавать то, что находится между изменяемыми кусками.
Потому реально — не объединяет.
тем не менее две последовательные записи он потенциально может объединить в одну,
Потенциально может, но зачастую путем потери во времени передачи данных. Например, при двух записях в FAT, вам придется передавать то, что находится между изменяемыми кусками.
Потому реально — не объединяет.
Видите в чем беда… Вы перфекционист. Вам кажется, что если уж оптимизация — так до полного упора. А это просто не нужно. Есть такое правило «20-80» (20% людей выпивают 80% пива). 20% возможных оптимизаций дают примерно 80% эффекта.
И не надо анализировать бут-сектор и считать размеры FAT. Ну хотя бы потому, что 90% людей флэшку не переформатируют. А из оставшихся — 95% форматирует с дефолтными параметрами. И того, настройкой на дефолтную разметку мы оптимизируем 99.5% случаев использования.
Остальное — никому не нужный перфекционизм.
И не надо анализировать бут-сектор и считать размеры FAT. Ну хотя бы потому, что 90% людей флэшку не переформатируют. А из оставшихся — 95% форматирует с дефолтными параметрами. И того, настройкой на дефолтную разметку мы оптимизируем 99.5% случаев использования.
Остальное — никому не нужный перфекционизм.
Видите в чем беда… Вы перфекционист. Вам кажется, что если уж оптимизация — так до полного упора. А это просто не нужно. Есть такое правило «20-80» (20% людей выпивают 80% пива). 20% возможных оптимизаций дают примерно 80% эффекта.
И не надо анализировать бут-сектор и считать размеры FAT. Ну хотя бы потому, что 90% людей флэшку не переформатируют. А из оставшихся — 95% форматирует с дефолтными параметрами. И того, настройкой на дефолтную разметку мы оптимизируем 99.5% случаев использования.
Остальное — никому не нужный перфекционизм.
именно введение оптимизаций для FAT можно назвать перфекционизмом. Такие попытки были. Например OTI 2169, там небольшой логический мини банк для блоков с FAT был. Но эта политика себя не оправдала. (это было во времена USB Flash 256Мб, 512МБ)
Ещё раз говорю — сделайте моделирование. И вы увидите, что алгоритмы оптимизированы под FAT.
Ещё раз говорю — сделайте моделирование. И вы увидите, что алгоритмы оптимизированы под FAT.пока не получили массового распространения файловые системы учитывающие аппаратные нюансы NAND flash, то FAT остается файловой системой, которая имеет минимальную паразитную нагрузку. Чуть поглубже погрузитесь в устройство той же Ext и понаблюдайте за всеми R/W операциями и проанализируйте места записей и посчитаете насколько паразитных записей будет больше.
Что значит «не получили массового распространения»? UBIFS, JFFS2 и LogFS более чем используются. Вы попробуйте найти устройство с linux, где не было было бы одной из этих систем!
Но именно с микросхемами NAND flash, а не с USB-флэш, в которой для этого есть собственный контролер.
Я вам уже посчитал — аж 4 на ext2 взамен всего 4х на FAT для коротких файлов (размером меньше кластера). При этом ext2 агрессивно кэшируется, в отличие от FAT на windows. Иногда после записи на флэшку делаешь sync и чуть ли не минуту ждет сброса дискового кэша. Так что реальных операций записи — сильно меньше.
Но именно с микросхемами NAND flash, а не с USB-флэш, в которой для этого есть собственный контролер.
посчитаете насколько паразитных записей будет больше.
Я вам уже посчитал — аж 4 на ext2 взамен всего 4х на FAT для коротких файлов (размером меньше кластера). При этом ext2 агрессивно кэшируется, в отличие от FAT на windows. Иногда после записи на флэшку делаешь sync и чуть ли не минуту ждет сброса дискового кэша. Так что реальных операций записи — сильно меньше.
Причины того, что USB flash у вас умирали с использованием Ext совсем в другом.
И в чем же они? Почему 4 записи на файл на ext2 вам кажутся сильно больше, чем 4 записи на FAT?
Возьмем к примеру USB Flash на старом контроллере и простой NAND
SK6211 (UFD) + NAND K9HBG08U1M -2шт.
Samsung NAND 8bit I/O, страница 2112 байт. 2 банка, 2 плоскости в банке. Микросхема умеет работать сразу с 2 плоскостями. Организация в блоки по 128 страниц. (128*2112=270336 байт).
2 микросхемы = 4 банка, в каждом банке по 2 плоскости. Контроллер реализует эти возможности. В итоге имеем параллельную симметричную запись по каждому из каналов сразу в 4 банка и в каждом сразу в две плоскости. Итого поток сразу по 8 «каналам». 8*128=1024 страницы — это размер блока (1024*2112=2 162 688), единица в трансляции, которой оперирует данный NAND контроллер.
Организация страницы: (особенность SK6211)
2112 байт из них 2048 — данные для LBA диапазона. 64 служебные. по 16 байт на каждый блок 512 байт. В каждые 16 байт входят несколько служебных байт с маркером и флагами (дублирующие информацию из транслятора) и ЕСС (БЧХ)
Трансляция:
Логический банк по 0x400 (1024 блока), реально включено в трансляцию 0x3Cx (количестве в каждом экземпляре будет разное в зависимости от количества заведомо забракованных блоков).
В таблице указываются порядковые номера блоков из которых формируется LBA диапазон.
пример работы NAND контроллера:
Допустим в блоке с логическим номером 3 лежит файл 2кб, мы его отредактировали и сохранили изменения. NAND контроллер прочитает целый блок 2МБ, внесет в буфере изменения в виде наших модифицированных 2кб очистит и перепишет целиком блок 2Мб, только вот при выборе куда записать не факт, что он выберет блок из котрого прочитал. Скорее выберет блок из тех, что не принимают участие в трансляции с меньшим значением счетчика перезаписей, выполнит в него запись содержимого буфера, отразит сие в трансляции. Аналогичные действия произведутся в областях содержащие метаданные файловой системы.
На вопрос с чего я решил, что данный контроллер работает именно так отвечу демонстрацией примера моей древней работы по реверс-инжинирингу http://www.flash-extractor.com/forum_old/viewtopic.php?t=758 (первое же сообщение с описанием сбора логического образа из дампов полученных из микросхем). Там описан только алгоритм сбора образа с пользовательскими данными в рамках ПО существовавшего в 2008 году.
SK6211 (UFD) + NAND K9HBG08U1M -2шт.
Samsung NAND 8bit I/O, страница 2112 байт. 2 банка, 2 плоскости в банке. Микросхема умеет работать сразу с 2 плоскостями. Организация в блоки по 128 страниц. (128*2112=270336 байт).
2 микросхемы = 4 банка, в каждом банке по 2 плоскости. Контроллер реализует эти возможности. В итоге имеем параллельную симметричную запись по каждому из каналов сразу в 4 банка и в каждом сразу в две плоскости. Итого поток сразу по 8 «каналам». 8*128=1024 страницы — это размер блока (1024*2112=2 162 688), единица в трансляции, которой оперирует данный NAND контроллер.
Организация страницы: (особенность SK6211)
2112 байт из них 2048 — данные для LBA диапазона. 64 служебные. по 16 байт на каждый блок 512 байт. В каждые 16 байт входят несколько служебных байт с маркером и флагами (дублирующие информацию из транслятора) и ЕСС (БЧХ)
Трансляция:
Логический банк по 0x400 (1024 блока), реально включено в трансляцию 0x3Cx (количестве в каждом экземпляре будет разное в зависимости от количества заведомо забракованных блоков).
В таблице указываются порядковые номера блоков из которых формируется LBA диапазон.
пример работы NAND контроллера:
Допустим в блоке с логическим номером 3 лежит файл 2кб, мы его отредактировали и сохранили изменения. NAND контроллер прочитает целый блок 2МБ, внесет в буфере изменения в виде наших модифицированных 2кб очистит и перепишет целиком блок 2Мб, только вот при выборе куда записать не факт, что он выберет блок из котрого прочитал. Скорее выберет блок из тех, что не принимают участие в трансляции с меньшим значением счетчика перезаписей, выполнит в него запись содержимого буфера, отразит сие в трансляции. Аналогичные действия произведутся в областях содержащие метаданные файловой системы.
На вопрос с чего я решил, что данный контроллер работает именно так отвечу демонстрацией примера моей древней работы по реверс-инжинирингу http://www.flash-extractor.com/forum_old/viewtopic.php?t=758 (первое же сообщение с описанием сбора логического образа из дампов полученных из микросхем). Там описан только алгоритм сбора образа с пользовательскими данными в рамках ПО существовавшего в 2008 году.
Честно говоря, я не знаю, что там было в 2008ом году. Насколько я помню — 1-2 гигабайтные флэшки тех времен довольно спокойно переживали посекторную запись.
А я про современные флэшки на 8 и 16 гигов.
А я про современные флэшки на 8 и 16 гигов.
Честно говоря, я не знаю, что там было в 2008ом году. Насколько я помню — 1-2 гигабайтные флэшки тех времен довольно спокойно переживали посекторную запись.
А я про современные флэшки на 8 и 16 гигов.
Я специально взял в качестве примера старый накопитель как значительно более простой пример в пояснении принципов работы. И кстати его размер 8Гб. Думаю Вам бы не стало проще понять принцип работы NAND контроллеров, если бы я добавил всякие нюансы с зашумливанием данных с исключением столбцов по плоскостям, несимметричной записью по каналам, нюансы с использованеим «блоков-апдейтов» и т. п.
Некоторые из этих нюансов позволяют дать приоритет в надежности для начальных логических блоков.
Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — S25FL256S
Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — S25FL256S
Некоторые из этих нюансов позволяют дать приоритет в надежности для начальных логических блоков.
Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — S25FL256S
каким боком приведенный пример flash памяти может относиться к USB Flash или различным CF, SD картам?
Ну значит такое качество у вас анализа было… :-)
Для оптимизации под FAT хватает того, что контролер считает, что часто перезаписываемая область находится в начале диска, а не в его середине или в конце
Скорее это не качество моего анализа, а Ваше незнание принципов работы накопителей на основе NADN flash. Дело в том, что адресное пространство не используется линейно. Есть понятие группировок NAND страниц в блоки из которых в трансляторе формируется логическое пространство (очень грубое упрощение). Так вот любой физический блок может выполнить любую логическую роль.
Эксперимент очень простой. Берете 5-10 неиспользованных флэшек разных моделей. Разбиваете на 2 раздела. Один — большой под FAT, второй в конце, 1-2 гига, под ext3. При попытке растарить на него почти гигабайтный архив — запись зависает примерно в половине случаев.
Ваш эксперимент с создание разделов в разных местах логического пространства ровным счетом ничего не показывает, кроме того, что в случае использования Ext на USB Flash они отваливаются при высокой нагрузке, что не лучшим образом характеризует качество изделий. Упреждая вопрос с кажущейся одинаковой нагрузкой в случае FAT и Ext предложу Вам обратить внимание на устройство файловых систем, чтобы понимать, какие метаданные файловой системы и куда пишутся, кроме непосредственно самих данных файла. Также обращаю внимание на то, что запись ведется преимущественно блоками (группа NAND страниц), т. е. перезапись метаданных Ext — это неслабая паразитная нагрузка, которая намного выше, нежели в случае FAT.
Так вот любой физический блок может выполнить любую логическую роль
Это не отменяет тот факт, что таблица FAT находится в начале логического пространства адресов.
Упреждая вопрос с кажущейся одинаковой нагрузкой в случае FAT и Ext предложу Вам обратить внимание на устройство файловых систем, чтобы понимать, какие метаданные файловой системы и куда пишутся,
Обычный режим для Windows — это частое (после записи каждого файла)обновление таблицы FAT. Причем для мелких файлов — меняется лишь один сектор в этой таблице. Винда обычно настроена так, чтобы выдергивание флэшке не привело к поломке FAT.
С другой стороны linux кэширует запись в служебные области, Причем время кэширования — достаточно велико.
Так что теоретически, при распаковке кучи мелких файлов, нагрузка на определенные сектора будет выше для FAT
Собственно можете сами попробовать писать секторами по 512 в начало и конец логического диска на USB. И сами увидите, что посекторная запись в конец быстрее вышибает диск.
Пес его знает.
Есть такая штука Raspberry Pi.
Штатная флэшка под нее разбита на два раздела. Сначала маленький FAT с несколькими текстовыми файлами настройки, а потом, кажется, Ext3 (точно не FAT), работает нормально, образ льется по dd нормально. Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода. Но и FAT (тоже постоянная запись с камеры, но не RPi) под большой нагрузкой умирает за примерно то же время.
Есть такая штука Raspberry Pi.
Штатная флэшка под нее разбита на два раздела. Сначала маленький FAT с несколькими текстовыми файлами настройки, а потом, кажется, Ext3 (точно не FAT), работает нормально, образ льется по dd нормально. Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода. Но и FAT (тоже постоянная запись с камеры, но не RPi) под большой нагрузкой умирает за примерно то же время.
Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода.потоковое видео, объем данных записываемых линейно достаточно велик. Накладные расходы на запись метаданных файловой системы невелики по отношению к размеру данных. При регулярной записи мелких файлов (как например при разархивации мелочи из архива), накладные расходы будут многократно выше и тип файловой системы сыграет роль.
Это не отменяет тот факт, что таблица FAT находится в начале логического пространства адресов.
начисто отменяет. блок с boot сектором и FAT может и в самом конце быть. За время эксплуатации он постоянно будет перемещаться. Чуть ли не при каждой перезаписи. В первый свободный блок с существенно меньшим числом записей.
Обычный режим для Windows — это частое (после записи каждого файла)обновление таблицы FAT. Причем для мелких файлов — меняется лишь один сектор в этой таблице.
для вас меняется один лишь сектор, а NAND контроллер целиком переписывает блок.
Винда обычно настроена так, чтобы выдергивание флэшке не привело к поломке FAT.от Windows и любой другой ОС тут мало что зависит. Если выдергивание произойдет во время обновления таблицы трансляции, то получите накопитель, который «перестал определяться» или «определяется нулевым размером».
С другой стороны linux кэширует запись в служебные области, Причем время кэширования — достаточно велико.
Так что теоретически, при распаковке кучи мелких файлов, нагрузка на определенные сектора будет выше для FAT
Если не брать в расчет принципы работы конкретного NAND контроллера, то иллюзия подобная вашей имеет место быть. А по факту на Ext нагрузка будет выше.
Собственно можете сами попробовать писать секторами по 512 в начало и конец логического диска на USB. И сами увидите, что посекторная запись в конец быстрее вышибает диск.
поверьте, данный детский эксперимент мне точно нет нужды проводить. Я все же предпочитаю более глубокий анализ принципов работы NAND контроллеров.
А как повлиять на производителей в плане улучшения поддержки сторонних FS? Тут разве предусмотрена какая-то обратная связь? Даже просто выбрать при покупке модель с поддержкой ext3/ext4, если таковые вообще существуют в природе, и то практически невозможно, потому как в характеристиках этого не указывают. Поддержку основных кодеков и видеоконтейнеров укажут, а такую мелочь — нет.
А как повлиять на производителей в плане улучшения поддержки сторонних FS?В том-то и дело, что они не сторонние, а нативные. В тех самых «приставках и телевизорах», в подавляющем большинстве случаев сидит Linux. А как влиять? Просить, требовать, искать прошивки, которые позволят вам использовать то, чего хотите. А как ещё?
Даже просто выбрать при покупке модель с поддержкой ext3/ext4, если таковые вообще существуют в природе, и то практически невозможно, потому как в характеристиках этого не указывают. Поддержку основных кодеков и видеоконтейнеров укажут, а такую мелочь — нет.Ну вот эту проблему и нужно решать.
А то у вас получается, что Linux не поддерживает Linux'овые технологии — а виноваты разработчики. Нет. Виноваты те, что взял — и открутил эту поддержку по тем или иным причинам.
UFO just landed and posted this here
Нет, не понимаю. Сходить к соседу с внешним USB-диском с фильмами — вполне реалистичная ситуация (не у всех ещё интернеты в сотни мегабит). И форматировать его в «Ext4, XFS, Btrfs» совершенно не годится, потому что у соседа на компе стоит не Android-x86, а Windows 7.
На флешке/переносном USB-винте должна стоять ФС, которая работает одновременно и на приставках, и на телевизорах, и на виндах. Если сосед — хипстер/дизайнер, то и в макосях тоже.
>Если сосед — хипстер/дизайнер, то и в макосях тоже.
с макосями дела не имел, но загуглив по-быстрому, получил, например
Mac OS X can read from NTFS drives, but it can’t write to them unless you use one of the below tricks.
то есть, насколько я понимаю, без предварительных танцев в макоси тоже не всё хорошо
с макосями дела не имел, но загуглив по-быстрому, получил, например
Mac OS X can read from NTFS drives, but it can’t write to them unless you use one of the below tricks.
то есть, насколько я понимаю, без предварительных танцев в макоси тоже не всё хорошо
UFO just landed and posted this here
Во-первых, я писал, что поддержка NTFS это плюс линуксу. Во-вторых, ещё раз повторюсь, конечным пользователям плевать, у кого какие там плюсы-минусы, им надо чтобы просто работало. «Ext4, XFS, Btrfs» под «просто работает» не попадает. Вот и всё. Не надо мне минусов надумывать, я ничего такого не говорил.
UFO just landed and posted this here
Что ж, рад за вас) К сожалению для всех нас, типичный конечный пользователь не такой. Он ближе к такому.
Не надо мне минусов надумывать, я ничего такого не говорил.Вы почему-то начали очень сильно напирать на «конечных пользователей», которым «наплевать» на всё на свете в ветке, которая, уж извините, началась со следующего диалога:
Однако если ты сталкиваешься с тем что у тебя чего не то не работает в опенсорце то открыв исходник можно как минимум понять почему, и вероятно, как минимум, найти обходной путь в виде условий при которых оно будет работать.
У Linux всё очень плохо с поддержкой железа и разных низкоуровневых фишек. Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
…
Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень.
Ну а дальше — уже откуда-то возникли «обычные пользователи», которым «всё пофиг», и которым, в частности, пофиг, что нормально Smart TV работает только с HDD, отформатированным в ext3.
Я отвечал на второй комментарий, который как раз и является мнением конечного пользователя, который просто хочет фильмов на диске. Ни к линуксу, ни к опенсорсу я никаких претензий не имею и прекрасно понимаю весь вложенный в них труд, я лишь констатирую факты касательно юзабельности всего этого по состоянию на май 2017 года. Как и автор второго комментария.
Как и автор второго комментария.Автор второго комментария, вы уж извините, начинает с того, что заявляет: чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено, притом что подавляющее большинство «железок» (как то: смартфоны и SmartTV, роутеры и суперкомпьютеры) сейчас только под Linux'он и работают.
Как было сказано чуть выше:
Виндовый чекдиск не умеет править линуксовые системы — минус линуксу. Линукс умеет править нтфс, но базово — снова минус линуксу.Это, вы уж извините, не «я лишь констатирую факты касательно юзабельности всего этого по состоянию на май 2017 года», а совсем даже другое…
Я отвечал лишь про файловые системы. Про оборудование я ничего не говорил и говорить не собираюсь (хотя сказать тоже много чего есть, я недавно 3G-модем не смог завести, например), только про файловые системы.
Как было сказано чуть выше:
Прекращайте перевирать мои комментарии, никому никаких минусов я не приписывал. Я лишь объясняю, что нельзя просто так взять и отформатировать флешку в Ext4. Если все ваши соседи юзают убунту, если все ваши приставки без проблем подключают Ext4, если ваш работодатель отказался от использования продукции Microsoft — я буду очень радоваться за вас и завидовать вашему локальному вендекапцу. Но, к сожалению, мир, в котором живу я (и автор второго комментария), не такой, мне приходится взаимодействовать с Windows каждый день (в том числе с использованием флешек), и, если я отформатирую флешку в Ext4, я получу кучу проблем при взаимодействии с другими людьми и их устройствами.
Ваш мир примерно так же несовершенен, как и мой — но какое это всё имеет отношение к качеству опен-сорсного кода, в частности, кода Linux'а?
я недавно 3G-модем не смог завести, например
Вы опять же путаете производителей софта и производителей железа.
То, что производитель вашего модема написал драйвер лишь к Windows — никак к теме не относится. У меня есть сканер, который работает лишь в WinXP x86. Начиная с висты и выше драйверов нет. Однако сканер прекрасно работает в любых версиях Linux. И будет работать ещё не одно десятилетие.
На флешке/переносном USB-винте должна стоять ФС, которая работает одновременно и на приставках, и на телевизорах, и на виндах. Если сосед — хипстер/дизайнер, то и в макосях тоже.
Тогда ntfs не очень подходит, т. к. её поддержка на macosx хуже на linux.
exFAT — ещё хуже, чем NTFS. По той же причине.
Есть где почитать про проблемы? В моей практике с ней было всё прекрасно, лучше чем с NTFS
На куче железок он не поддерживался по тем же причинам: патенты. Какая сейчас ситуация в ванильном линуксе — не знаю. Apple вполне может оплачивать лицензию.
Wikipedia не подойдёт?
Там про всё написано: и про проблемы с патентами и лицензиями и про Samsung'овский драйвер с непонятным правовым статусом и про прочее.
Разница в основном в том что, что exFAT разрабатывался под весьма убогое ядро Windows CE (и, соответcтвенно, под «хитрый план» связанный с вытеснением Linux'а со всяких «приставок и Smart TV»), так что хитрых фич в ней меньше.
Там про всё написано: и про проблемы с патентами и лицензиями и про Samsung'овский драйвер с непонятным правовым статусом и про прочее.
Разница в основном в том что, что exFAT разрабатывался под весьма убогое ядро Windows CE (и, соответcтвенно, под «хитрый план» связанный с вытеснением Linux'а со всяких «приставок и Smart TV»), так что хитрых фич в ней меньше.
Всё в порядке. Просто в UI доступном для "ЦА" её намеренно вырезали. Вот так вот, да. Замкнутый круг. Нету — потому что ЦА не поймёт, а ЦА никогда не поймёт потому что нету.
UFO just landed and posted this here
UFO just landed and posted this here
В Windows в любимой вами NTFS поддерживается значительно больше прав доступа безо всяких ограничений на число тех, к кому они применяются.В случае с безопасностью «больше» не значит «лучше». Что система прав Windows гибче — однозначно. А вот безопаснее ли она — это большой вопрос.
Да и selinux — это не «костыль к системе прав». Это вы его с xattr, перепутали, я думаю.
С исправлением согласен.не ходи с уставом и привычками одной ОС по другим ОС
Исправил.
Вообще есть много вещей, которые в Linux и Windows сделаны по разному — причём так, что сходу сказать «что лучше» — нельзя. Например в Windows интерфейс системных вызовов (syscalls) — нестабилен, что приводит к тому, что многие вещи, которые в FreeBSD/Linux можно сделать в Windows в принципе не поддерживеются — но зато это позволяет делать межмодульные вызовы быстрее. И? Какой из подходов лучше? Зависит от ваших целей, разумеется.
Собственно отсюда и появляется явление, которое неправильно описано G-Tigerом как стоит кому-то что-то сказать на эту ОС, как тут же откуда-то прилетают минуса.
Минуса появляются не тогда, когда кто-то заявляется «Linux не умеет X, а Windows — умеет», а когда кто-то из этого делает «глубокомысленный» вывод «потому Linux — отстой». Ибо это как раз и есть попытка «ходить с уставом и привычками одной ОС по другим ОС».
UFO just landed and posted this here
UFO just landed and posted this here
Это весьма сложно, скажу я вам. Получать права на файлы, пытаться удалить заблокированные… Ну нафиг, сложно это.Ничего сложного. Запустить консоль с повышением прав и выполнить
del /s /f /q "C:\Program files\*"
del /s /f /q C:\Windows\*И посмотреть, как обновление системы восстановит потерянные файлы )))
UFO just landed and posted this here
Натурный эксперимент, проведённый несколько лет назад доказал, что всё это, в общем, сказки: система зачхастую отказывалась грузиться и гораздо чаще «полностью вернуть работоспособность испорченных систем не удалось» — и это были не Windows 95…
И что вы этим хотели сказать? Зачем восстанавливать то, что не удалено?Как минимум, ядро ntoskrnl.exe и все драйвера в System32\Drivers не заблокированы. Значит, система не загрузится в следующий раз.
UFO just landed and posted this here
Попробуй свою венду скопировать на другой диск чтобы она потом ещё и работала. Штатными средствами.Может, глупость спрошу, но разве средство резервного копирования и восстановления с настройкой создания образа системы (или любого другого выбранного NTFS-раздела, доступного системе) с этим не справляется?.. Вроде, оно для чего-то подобного и сделано.
Оно делает образ системы в виде виртуального жёсткого диска VHD, который можно закинуть почти куда угодно (на NTFS-раздел, естессно) и загрузиться прямо с него, добавив соответствующую запись в список загрузки BCD.
UFO just landed and posted this here
злобный монополист захватил кучу сопутствующих рынков встроенными приложениям в ОС с монопольным положением на рынке ОСДа, бородатый прикол. Частично решался размещением горки бесплатного доп.софта на официальном сайте.
лохи, не смогли создать такую простую утилитуУгу, коммерческой компании делать больше нефиг, как тратить тысячи лишних человеко-часов разработчиков ради тонны круто написанных утилит на любой вкус/цвет/запах, которые, раз они так круты, скорее всего, моментально спиратят. И так-то их софт по торрентам гуляет вовсю.
Тот же GNU/Linux создавался десятками компаний и кучей энтузиастов. Попутно разный прикладной свободный софт пришёл и на другие платформы, включая столлманно-мерзкую венду.
не кормите егоДа просто было любопытно потыкать палочкой очередного «винда нифига не умеет!!11адынадын», не удосужившегося сделать то, что посильно простому вендоюзеру, — заглянуть в настройки резервного копирования, в папку с бэкапами и немного подумать.
UFO just landed and posted this here
Какое-то время назад с другом по телефону чинили сломанный NTFS как раз через ntfsfix с помощью лайв-убунты, потому что винда не грузилась, а чекдиск циклически проверял диск, перезагружался, снова ругался на сломанный нтфс и снова предлагал починить. На 5 раз стало очевидно, что надо что-то делать. Убунту, руфус, полчаса и готово. Винда грузится, все довольны.
Так что я не знаю, что у вас за траблы с нтфсом в линухе. Тем более, как выше уже сказали, поддержка формата без спецификации то еще удовольствие.
1) "вот эти экзотические Linux'овые ФС", на самом деле, используются на куда бОльшем количестве девайсов в мире, чем существует ПК с Windows
2) Почему вы Linux'у в претензию ставите отсутствие нормальной поддержки проприетарной и абсолютно не документированной ФС, все имплементации которой получены только реверс-инжинирингом, при этом не ставите Windows в вину отсутствие нормальной поддержки не только ExtFS, но и других "вкусняшек", код которых полностью открыт (т.е. давно бы уже могли, если бы не принцип EEE)? Вы сами не видите за собой двойных стандартов?
3)
У Linux всё очень плохо с поддержкой железа
a) это не вина Linux. Это вина вендоров. Иногда в лени и/или жадности и/или глупости (незнании о существовании чего либо кроме Windows), иногда в сговоре с M$ явно запрещающем писать драйвера для других ОС (да-да).
b) на самом деле, это наглая ло^W^W совсем не так. Я сменил уже порядка 3 лаптопов "игрового" класса (сейчас, вот, пишу с MSI GT-72 купленного год назад) и всё железо в них прекрасно поддерживается. Даже смена окраски клавиатуры.
и разных низкоуровневых фишек
Не соблаговолите ли вы быть немного более конкретным? Иначе сие так же суть подлог и провокация.
Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
От первого до последнего слова подлог и провокация.
Ну и сама суть:
взять проприетарную ОС с проприетаной ФС
В винде я бы сделал chkdsk и всё, а в Linux не могу
LINUX КАКАШКА НЕ ПОДДЕРЖИВАЕТ САМУЮ ПОПУЛЯРНУЮ ФС А ВИНДА РУЛИТ ПОТОМУ ЧТО ПОТОМУ
В винде нету поддержки ни одной из кучи других (зачастую более лучших) ФС (кстати, некоторые из поддерживаемых Linux'ом ФС старше самой Windows раза в два-три).
ЭКЗОТИЧЕСКИЕ ФС!!!!!!1111
Ну, детский сад же, ну.
UPD.: забыл ещё сказать:
Практически все эти "умные телевизоры" используют Linux и умеют эти все ФС. Просто вендоры — ну… вендоры. Короче. "ЦА не поймёт — значит выкидываем".
Практически все "приставки" (STB и т.п.) — тоже линуксы и то же самое.
Игровые — либо линуксы либо другие юниксы и то же самое
Если речь про какие-то банальности, обнаруживаемые filemonом и иже с ним или вообще абстрактно — да, исходники иметь лучше, чем не иметь их…
другой вопрос, что скорее всего читающий совсем не программист, либо «программист» (админ/эникей), либо специалист по другому языку и не понимающий указатели на указатели…
читающий совершенно не знает проект
читающий, даже примерно найдя проблему не сможет «быстренько скомпилировать» сие
нет никакой гарантии, что фикс проблемы с «правами к папке» в итоге не будет теперь выдавать всем рута.
и тд.
другой вопрос, что скорее всего читающий совсем не программист, либо «программист» (админ/эникей), либо специалист по другому языку и не понимающий указатели на указатели…
читающий совершенно не знает проект
читающий, даже примерно найдя проблему не сможет «быстренько скомпилировать» сие
нет никакой гарантии, что фикс проблемы с «правами к папке» в итоге не будет теперь выдавать всем рута.
и тд.
«Холивар он такой».
Вы ребя нашли очередной стимул к разодрать старую рану. Не могу пройти мимо…
Винда — она такая лапочка…
Линуx — такой брутальный…
Винда — лимузин…
Линуx — внедорожник(джип)…
Мы уже наверно подошли к пониманию, что сравнивать их можно косвенно. Роскошный лимузин и проходимый жип — оба являются представителями автомобилей. И толку сравнивать эти классы? Давайте обсудим закрытость и открытость этих систем. Бессмысленно! первокурснику понятно, что…
Итого:
1) В рейтинге закрытых систем абсолютный лидер и монополист — Винда. Карсочная, гладкая, вылизанная и причёсанная. Эх одна отрисовка шрифтов чего стоит…
В этой категории iOS даже «краем глаза» не приблизится к мастдаю. Единтственное — это перформанс, тут конечно яблоковцы гуру. Однако iOS — основывается на открытом коде линукса, что у же выбивает его из вышеназванной категории, да и много ещё к чему подкопаться можно. Например, многие кодят в среде iOS, пишут музыку и рисуют фильмы картинки. Вот ток вопрос, в ограниченности предоставленных инструментов полюбому открыт.
Кого ещё можно затронуть в этой категории?..
2) В рейтинге открытых систем — есть много игроков, но все они брутальны. В том плане, что это либо для гиков, админов промышлеников и тд/тп, либо это десктопы, которые никак не сравнить с вышеупомянутыми лидерами.
По ходу кроме «яблока Джобса» с червоточинкой, некому в этом мире написать достойную пусть и закрытую операционную систему.
Вы ребя нашли очередной стимул к разодрать старую рану. Не могу пройти мимо…
Винда — она такая лапочка…
Линуx — такой брутальный…
Винда — лимузин…
Линуx — внедорожник(джип)…
Мы уже наверно подошли к пониманию, что сравнивать их можно косвенно. Роскошный лимузин и проходимый жип — оба являются представителями автомобилей. И толку сравнивать эти классы? Давайте обсудим закрытость и открытость этих систем. Бессмысленно! первокурснику понятно, что…
Итого:
1) В рейтинге закрытых систем абсолютный лидер и монополист — Винда. Карсочная, гладкая, вылизанная и причёсанная. Эх одна отрисовка шрифтов чего стоит…
В этой категории iOS даже «краем глаза» не приблизится к мастдаю. Единтственное — это перформанс, тут конечно яблоковцы гуру. Однако iOS — основывается на открытом коде линукса, что у же выбивает его из вышеназванной категории, да и много ещё к чему подкопаться можно. Например, многие кодят в среде iOS, пишут музыку и рисуют фильмы картинки. Вот ток вопрос, в ограниченности предоставленных инструментов полюбому открыт.
Кого ещё можно затронуть в этой категории?..
2) В рейтинге открытых систем — есть много игроков, но все они брутальны. В том плане, что это либо для гиков, админов промышлеников и тд/тп, либо это десктопы, которые никак не сравнить с вышеупомянутыми лидерами.
По ходу кроме «яблока Джобса» с червоточинкой, некому в этом мире написать достойную пусть и закрытую операционную систему.
> iOS
Может быть все же OS X?
iOS — это планшеты и смарты, которые пока уделывают виндоконкурента по полной программе.
Впрочем, и в OS X, и в iOS не используется линуксовое ядро. Там, если не путаю, используется своеобразное юниксовое ядро mach64, причем творчески переработанное.
И да, OS X официально сертифицировано как UNIX система, Linux нет.
Может быть все же OS X?
iOS — это планшеты и смарты, которые пока уделывают виндоконкурента по полной программе.
Впрочем, и в OS X, и в iOS не используется линуксовое ядро. Там, если не путаю, используется своеобразное юниксовое ядро mach64, причем творчески переработанное.
И да, OS X официально сертифицировано как UNIX система, Linux нет.
В дистрибутивaх Linux менеджер пакетов — де-факто стандарт. В отличие от тех же BSD, где есть четкая граница между нeделимой базовой частью системы и набором установлeнных поверх нее портов/пакетов, дистрибутивы GNU/Linux состоят исключительно из пакeтов. Ядро — отдельный пакет, базовый набор утилит команднoй строки — другой пакет, библиотека libc (главная часть системы после ядpа) — еще один пакет.
Такое разделение не случайно, это сама суть GNU/Linux — множество написанных разными людьми компoнентов, которые работают сообща. Но у этого подхода есть множество проблем. За сохранением зависимостей между пакeтами необходимо строго следить; замена всего лишь одного системного пакeта может привести к неработоспособности всей сиcтемы. Для обновления дистрибутива до новой версии приходится придумывать кoстыли: обновлять все базовые компоненты дистрибутива необходимо так, чтобы сиcтема не осталась в пограничном состоянии (когда часть пакетов обнoвлена, а часть нет).
Ну и конечно же, известное всем линуксоидам огpаничение, когда ты просто не можешь установить две разные версии приложения. Содeржимое пакета копируется в системные каталоги вместо своего выдeленного, а даже если установка в выделенный каталог возможна, наверняка возникнут проблемы с зависимостями: прилoжение требует библиотеку libxyz.1.2, а в системе установлена libxyz.1.3, и ее версию нельзя понизить, потому что пакeтный менеджер начнет ворчать, что приложения abc и bca требуют именно вeрсию 1.3.
Такое разделение не случайно, это сама суть GNU/Linux — множество написанных разными людьми компoнентов, которые работают сообща. Но у этого подхода есть множество проблем. За сохранением зависимостей между пакeтами необходимо строго следить; замена всего лишь одного системного пакeта может привести к неработоспособности всей сиcтемы. Для обновления дистрибутива до новой версии приходится придумывать кoстыли: обновлять все базовые компоненты дистрибутива необходимо так, чтобы сиcтема не осталась в пограничном состоянии (когда часть пакетов обнoвлена, а часть нет).
Ну и конечно же, известное всем линуксоидам огpаничение, когда ты просто не можешь установить две разные версии приложения. Содeржимое пакета копируется в системные каталоги вместо своего выдeленного, а даже если установка в выделенный каталог возможна, наверняка возникнут проблемы с зависимостями: прилoжение требует библиотеку libxyz.1.2, а в системе установлена libxyz.1.3, и ее версию нельзя понизить, потому что пакeтный менеджер начнет ворчать, что приложения abc и bca требуют именно вeрсию 1.3.
"Для desktop решений, говоря примитивно, ад. "
С конца 80-х использовал Unix/Xenix, с середины 90-х — desktop — Linux. И не разу не пожалел. Утверждаю — ад это Microsoft. Просто не тот desktop берете!!!!
Попробуйте разработать DLP такое же как под Windows — универсальное. Например для фильтрации устройств которые нужно блокировать. В Linux нет центрального PnP.
Попробуйте разработать шифрование загрузочного диска (на уже установленной системе, а не во время установки). В Linux, отсутствует множество механизмов для таких задач, например фильтрация. Приходиться делать через remapping устройств. А после нужно переконфигурировать Linux, на новое блочное устройство. И разные версии Linux конфигурируются по разному. Я уже не говорю что нужно парсить текстовый файл с этой целью.
Я перечислил только то, что мне в голову пришло. На практике примеров значительно больше.
Попробуйте разработать шифрование загрузочного диска (на уже установленной системе, а не во время установки). В Linux, отсутствует множество механизмов для таких задач, например фильтрация. Приходиться делать через remapping устройств. А после нужно переконфигурировать Linux, на новое блочное устройство. И разные версии Linux конфигурируются по разному. Я уже не говорю что нужно парсить текстовый файл с этой целью.
Я перечислил только то, что мне в голову пришло. На практике примеров значительно больше.
Давно отказался от виндузового ада на своем десктопе и использую openSUSE. И проблем меньше, и недостающих механизмов больше.
Справедливости ради, прямой путь для решения подобных проблем в случае закрытых исходников — не тот, который вы указали, а «написать в Майкрософт, с указанием примера, воспроизводящего проблему, и пусть они сами с ним разбираются».
Именно так я и поступил. Об этом было отрапартовано в Microsoft, еще год назад. И несколько месяцев назад я вел переписку с ними.
А какое решение приняло Microsoft? Баг будут исправлять?
Об этом мне не доложили. Мне только дали понять что в соответствии с их терминологией, подобная ошибка не является уязвимостью.
Точно не надо никаких привилегий для открытия $mft?
Наверняка, они имеют в виду, что если ты можешь выполнить подобный код, то ты УЖЕ на клиентской машине и можешь уже сделать и что-то более нехорошее. On the other side of airtight hatch, как пишет Рэймонд Чен.
Наверняка, они имеют в виду, что если ты можешь выполнить подобный код, то ты УЖЕ на клиентской машине и можешь уже сделать и что-то более нехорошее. On the other side of airtight hatch, как пишет Рэймонд Чен.
Интересно, а такое является: https://htrd.su/wiki/zhurnal/2017/04/24/ideja_dlja_badusb? В посте озвучено описание проблемы (т.е. не совсем идея) с которой столкнулся на проекте.
И каковы результаты?
Пока никаких)
На моей памяти, мы репортили три бага
Первый баг — приняли как баг, потом в kb/hf можно было увидеть, кто зарепортил.
Второй баг — приняли, но что стало не помню.
Третий баг — самый сложный, ибо его воспроизведение занимало 36 часов, и я уже ушёл из той конторы.
Если я правильно понимаю, политика принятия багов таки изменилась с тех пор.
- Ошибка с таймаутом в NetBIOS/IPX/SPX в эээ NT4, кажись
- В 2000 ошибка в MMC
- Утечка в SQL Server где-то в 2001-2002г
Первый баг — приняли как баг, потом в kb/hf можно было увидеть, кто зарепортил.
Второй баг — приняли, но что стало не помню.
Третий баг — самый сложный, ибо его воспроизведение занимало 36 часов, и я уже ушёл из той конторы.
Если я правильно понимаю, политика принятия багов таки изменилась с тех пор.
Каким образом (путем) вы репортили баги? Я пытался дважды зарепортить кое-что, ни разу не смог добиться какого-то ответа.
Один раз это было на форуме OSR. Давно. Человек из Microsoft, ответил что зафиксировал. Недавно была переписка через secure@microsoft.com.
Тогда, давным-давно это было ссылкой в msdn-е, оттуда. Дальше — перепиской.
Угу. А когда мне потребовалось, меня послали, ну не 3 буквы, но «пишите на форум technet, если никто не даст ответа, и это окажется действительно ошибкой, то мы свяжемся. Если тема „не взлетит“, создайте еще раз (sic)», потом послали меня в твиттер техподдержки клиентов, где пообещали выделить инженера для рассмотрения вопроса, но все так и осталось без ответа.
Реальная популярность Windows и Linux на десктопах несколько опровергает Ваше мнение о том, что именно первостепенно.
Доступ к исходникам можно получить — https://www.microsoft.com/en-us/sharedsource/
Только это можно не всем и не всегда бесплатно. 10 000 рабочих станций под Windows и Enterprise Agreement, юридическое лицо в особо доверенной стране — и код ваш.
Только это можно не всем и не всегда бесплатно. 10 000 рабочих станций под Windows и Enterprise Agreement, юридическое лицо в особо доверенной стране — и код ваш.
Попытаться отправить в апстрим, получить ответ, что это ломает ххх версии ууу девяносто забытого года. И поддерживать свой патч в своей организации до победного конца.
Простите что я написал не так:
Запускаю ничего не виснет ;(
PS. Win XP SP3
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
int main()
{
CreateFileW(L"C:\\$mft\123", FILE_READ_ATTRIBUTES, 0, NULL, OPEN_EXISTING, 0, NULL);
return 0;
}
Запускаю ничего не виснет ;(
PS. Win XP SP3
В коде ошибка. Не L«C:\\$mft\123», а L«C:\\$mft\\123». Так заработает.
ХМ исправил, либо я не пойму что должно случится, либо ничего не происходит. Выложите свой тестовый пример в откомпилированном виде.
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
int main() {
CreateFileW( L"C:\\$mft\\123", FILE_READ_ATTRIBUTES, 0, NULL, OPEN_EXISTING, 0, NULL );
return 0;
}
Просто скопируйте этот код, и соберите еще раз. После того как запустите, создайте папку на диске C. Должно зависнуть. Эффект не всегда мгновенный. Как правило, в пределах первой минуты будет результат.
Только что проверил на Windows XP. Действительно не зависает. Извиняюсь за ошибку.
Начиная с Windows Vista, зависает. Только что проверил. Спасибо.
На 10 протестили тоже не повисла.
Проверил на Win7 достаточно в консоли написать
cat c:\$mft\123Откорректировал материал, Вам спасибо!
Ну тут всё ещё веселей если например использовать такой путь как url картинки, то Chrome нормально отрабатывает, а вот IE валит систему.
Пишите статью, уверен будет интересно.
Firefox тоже валит — я решил сперва протестировать на себе, прежде чем писать тут комментарий :)
Валит не сразу, примерно с минуту всё нормально, потом всё намертво висит.
<ims src="file://c:/$mft/123">
Валит не сразу, примерно с минуту всё нормально, потом всё намертво висит.
Пошла импровизация)))
Проверил у себя, Win7 со всеми обновлениями:
1. Opera 12.18, Firefox 53, Vivaldi 1.9 — валят систему ТОЛЬКО если файл с таким урлом открыт с локального диска. Если его же открыть по HTTP с удалённого веб-сайта, то доступ к локальному файлу не производится, и система не зависает.
2. IE 11 — плевать хотел на безопасность, даже при открытии по HTTP сразу лезет грузить локальную картинку и всё вешает.
1. Opera 12.18, Firefox 53, Vivaldi 1.9 — валят систему ТОЛЬКО если файл с таким урлом открыт с локального диска. Если его же открыть по HTTP с удалённого веб-сайта, то доступ к локальному файлу не производится, и система не зависает.
2. IE 11 — плевать хотел на безопасность, даже при открытии по HTTP сразу лезет грузить локальную картинку и всё вешает.
Попробуйте вместо картинки сделать редирект на этот адрес или открыть url в iframe.
Аналогично. Нормальные браузеры послылают локальные ссылки лесом что в iframe, что в редиректе; IE радостно хавает и то, и другое. (Проверял только по HTTP.) Редирект смотрел только http-equiv. По-хорошему, надо бы потестить и через 301, и через JS, плюс картинку попробовать через тот же JS проинициализировать, но и так уже много времени убил.
Я думал, браузеры уже давно не открывают локальные ресурсы по ссылкам с внешних страниц.
Ну я тоже так думал, но мы тут только что успешно завесили несколько Windows7-машин через урл в теге img :)
Ну так браузеры и не открывают. Открывает только IE. ;-)
Точно. Кроме браузеров. Есть же и другие программы, которые по ссылкам умеют лазить, в том числе и производства Микрософт. Что у нас есть? Скайп какой-нибудь, антивирусы. Например, что-нибудь такое в архиве прислать, чтобы Windows Defender поискал хитрый путь. Есть что поисследовать.
Это да, простор в любом случае открывается широкий.
Ярлык.lnk можно сделать — я лет уже 17 назад как-то открыл файл ярлыка текстовым редактором доснавигатора и случайным образом потыкал в клавиши, а потом сохранил. После этого Windows Explorer и Windows Commander зависали в папке с этим ярлыком. Жаль, я не сохранил этот файлик себе на память.
Да это же знаменитый con/con bug из Windows 98!
Win8.1 со всеми обновлениями dir c:\$mft\123 — зависает сразу-же, при попытке перезагрузки синий экран.
Отформатировал флэшку под NTFS. Думал, выну ее из разъема после эксперимента, и все будет в порядке. Как бы не так. После выполения указанной вами команды съемный диск остается, explorer зависает, taskmgr не запускается.
Ничего себе! Ну, всё, конец терминальным серверам, учитывая простоту кода.
Ничего в мире не меняется, сразу вспомнил con bug.
c:\con\con 2.0
Если не считать это уязвимостью, при том, что удалённый доступ злоумышленнику по сути не нужен, то я теряюсь, что можно считать.
Не понял всего ужаса фразы, но звучит устрашающе:
"… если выполнить перезагрузку, то система повиснет на ней".
Т.е. после таких экспериментов система перестает загружаться от слова «совсем»?
Чем в таком случае лечить? Диагностика ФС из набора MS DaRT помогает? Или какие сторонние средства?
"… если выполнить перезагрузку, то система повиснет на ней".
Т.е. после таких экспериментов система перестает загружаться от слова «совсем»?
Чем в таком случае лечить? Диагностика ФС из набора MS DaRT помогает? Или какие сторонние средства?
Диагностика ни чем не поможет. Говоря о повисании на перезагрузке, я имел в виду что экран перезагрузки будет висеть вечно. И поможет только hard reset. Далее система загрузиться нормально. Также, этот случай актуален только когда мы выполним обращение к такому файлу не на системном томе.
У-ф-ф… Напугали… А я думал уже, что кирдык всей ФС, причем неремонтируемый даже при загрузке с диска MS DaRT. И Hard Reset не в помощь…
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
UFO just landed and posted this here
создал html файл chrome — путь валит намертво систему, проверил на себе. Пришлось кнопкой перезагрузиться. Собрал исходник, синий экран мгновенно.
Windows 7 Максимальная
Windows 7 Максимальная
Надеюсь MS выпустят вскоре фикс к этому, а то ведь сейчас 100% найдутся «особо одаренные», которые будут «развлекаться» этим способом, благо особых познаний в воспроизведении бага не требуется…
Попробовал в опере. Если открыть html с такой картинкой с src на локальном диске, то система виснет. Если же открыть такую страницу по http, то не виснет.
Да, будет работать только в IE.
См. деанонимизируем пользователей Windows и получаем учетные данные Microsoft и VPN-аккаунтов. Там как раз картинка, которая не на habrastorage, и перенаправляет на file://, если статью открыть в IE.
См. деанонимизируем пользователей Windows и получаем учетные данные Microsoft и VPN-аккаунтов. Там как раз картинка, которая не на habrastorage, и перенаправляет на file://, если статью открыть в IE.
mkdir \\pcname\c$\$mft\text если хватит прав тоже вешает удаленный комп.
Еще одна вредоносная программа.
Маленький шаг человека, большой шаг для человечества маленький баг в драйвере — большое поле возможностей для вандалов всех мастей… хе-хе…
В NTFS разделе вроде не только $mft служебный файл есть. К тому-же бывает NTFS-раздел примонтирован не только к букве раздела, а ещё и в каталог другого раздела ($mft в середине пути)
Как я понял: достаточно запросить "запрещённый путь" к разделу смонтированному на запись и при следующей операции записи произойдет зависание драйвера.
Из этого следуют потенциальные угрозы:
- Ярлык (на файл любого типа) ссылающийся на ресурс в запрещённый путь и/или в нем путь к иконке в запрещённом пути.
- Документ ЛЮБОГО типа, поддерживающий ссылки на ресурс в другом файле (не только HTML страницы).
- Сообщение в Мессенджере, делающем предварительный просмотр по ссылке ( Viber точно пытается показать картинку по ссылке)
- Браузеры + кэш файлов
5 Все Редакторы к п.2 (MS офис, либре-офис и т.д.) + п.2
6 Антивирусы + п.1, 2,4 (периодические и неожиданные зависания системы :)
7 Служба индексирования + п.1, 2,4 (периодические и неожиданные зависания системы)
8 Терминальные серверы и все выше описанное
9 Кэширующий сервер на Windows + п 6, 7
…
можно и дальше продолжить....
Можно еще добавить обычные почтовые клиенты. Получаешь письмецо, а там…
Не очень понял про кэширующий сервер на Windows. Как вы представляете атаку на него? Или вы имеете в виду случай, когда NTFS-раздел примонтирован к каталогу?
Не очень понял про кэширующий сервер на Windows. Как вы представляете атаку на него? Или вы имеете в виду случай, когда NTFS-раздел примонтирован к каталогу?
Как я понял: достаточно запросить "запрещённый путь" к разделу смонтированному на запись и при следующей операции записи произойдет зависание драйвера.
Неправильно понял. Достаточно операции "я только посмотреть", и раздел может быть "только для чтения", прав не нужно никаких.
TrueCrypt. Раздел ntfs только для чтения, как сменный носитель. При попытке чтения некорректного пути закрывается доступ к разделу.=> Попытка отмонтировать раздел убивает драйвер TrueCrypt и закрывается доступ к другим открытым разделам TrueCrypt. => Попытка доступа к любому разделу TrueCrypt вешает систему.
Флешка: попытка доступа к неадекватному каталогу на ней убивает доступ (на время сессии) ко флешке. => Попытка "безопасно отсоединить" флешку убивает систему.
UFO just landed and posted this here
Наверное не совсем корректно называть недостатки драйвера работающего со структурами NTFS багом самой NTFS.
О каком недостатке идет речь, когда ERESOURCE $mft файла не отпускается в случае fail?
Получилось в WIndows 2008R2 с последними обновлениями. Зависает и при запуске программы из поста, и при выполнении dir, и при открытии html-файла c (проверял на Firefox ESR и на IE).
Кстати, поверхностный поиск в гугле ничего не дал. Интересно, почему так — это же натурально бомба для тех же терминальных серверов. И защититься от этого, я так понимаю, невозможно?
Кстати, поверхностный поиск в гугле ничего не дал. Интересно, почему так — это же натурально бомба для тех же терминальных серверов. И защититься от этого, я так понимаю, невозможно?
Как только исправят
На терминальных серверах можно попробовать запретить пользователям чтение и запись С:/ не включая вложеные файлы и папки. А на остальные оставить как есть.
Не поможет. Ломается-то процесс поиска файла по указанному пути — а он выполняется до проверки прав.
Но даже если бы получилось закрыть доступ к диску C: — как в таком случае предполагается этим сервером пользоваться?
Действительно, ошибся.
Доступ запрещается только до корня диска С:/ а, доступ к остальным папкам и файлам в этом случае не меняется
Доступ запрещается только до корня диска С:/ а, доступ к остальным папкам и файлам в этом случае не меняется
Так проблема-то не в корне C:\, а в файле C:\$mft
Не так выразился… Доступ запрещается на чтение и запись файлов на диске С, но на папки не распространяется. Если я верно понимаю.
Надо будет потестить на виртуалке
Надо будет потестить на виртуалке
UPD.
Проверил на виртуалке с Win 8.1 со всеми обновлениями — не помогло
Проверил на виртуалке с Win 8.1 со всеми обновлениями — не помогло
Если не трудно, проверьте внешний запрос к IIS (internet server от микрософт) типа такого: http://%systemdrive%/$mft/testPath/TestPicture.jpg
Если уронит систему, то все…
Если уронит систему, то все…
http:// ip-адрес/%systemdrive%/$mft/testPath/TestPicture.jpg
Опечатка в предыдущем тексте
Опечатка в предыдущем тексте
Установил компоненты IIS, потестил по всякому, пока все нормально, при этом dir c:$mft\123 в консоли так же перестал вешать систему, страно…
Завтра займусь тестированием на разных версиях Windows
Завтра займусь тестированием на разных версиях Windows
А с какого перепугу IIS должен был выходить за пределы корня сайта при запросе с %systemdrive% в URL?
Был у меня сон " а ля Бальзаминов" — все спрашивают, как ты там- ответить не могу.
Статья добралась до Ars Technica
https://arstechnica.com/information-technology/2017/05/in-a-throwback-to-the-90s-ntfs-bug-lets-anyone-hang-or-crash-windows-7-8-1/
Очень круто, спасибо за публикацию
не обязательно прогу создавать, подходит bat файл:
echo "" >> c:\$fmt\0
Баг в NTFS, или как подвесить всю систему