Comments 305
Вопрос открытых или не открытых исходных кодов ОС — это вещь первостепенная. Сколько литров кофе потратили сотрудники компании во время реверс-инжиниринга, сколько нервных клеток пало в неравной борьбе с плохо протестированным кодом? И все равно пофиксить эту уязвимость типа «отказ в обслуживании» своими силами нельзя — исходников нет, и даже если написать свой фильтр-драйвер и проверять все вызовы NtCreateFile, то для такого драйвера нужна подпись Майкрософт, а она есть не у всех.
Если бы исходники были открыты, достаточно было бы взять отладчик, поставить брейкпоинт, заменить пару строчек, пересобрать модуль и готово.
проекты с открытым исходным кодом часто содержат ошибки, которые опытный разработчик никогда не допустит
В проприетарном ПО всё то же самое, только мы этого не видим, потому что код закрытый, ваш кэп :)
А неготовность линукса для десктопа связана не с открытостью, а с бесплатностью (даже какому-нибудь каноникалу не хватает ресурсов, в первую очередь денег на программистов, чтоб исправить всё и сразу) (хотя можно сказать, что бесплатность это следствие открытости, но вроде не всё так просто)
Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте».
Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте»
Эта позиция всё же оказывается чуть лучше и понятнее чем "вам надо — ждите, держитесь там и всё такое".
Всё же разработчик 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 читали? Ну так просветитесь…
Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».
Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».Это в части декомпиляции, создания резервных копий и прочего.
«Внесение в программу для ЭВМ или базу данных изменений» и «исправление явных ошибок» — это пункт 1280 подраздел 1 параграф 1. В нём — никакой размытости: «если иное не предусмотрено договором с правообладателем» и точка.
Ещё бы без уничижительно-поучительного тона, было бы совсем хорошо.
Вот взять хотя бы NTFS, раз уж статья о ней. Как-то обнаружил, что на внешнем USB-диске появились ошибки: имя одного из файлов сменилось на кашу из символов, и удалить этот файл не выходит — пишет, что файл повреждён.
В винде я бы сделал chkdsk и всё, а в Linux вдруг с удивлением обнаружил, что там полностью отсутствует мало-мальски функциональный инструмент для исправления NTFS-ошибок. Всё, что может мне предложить Linux — это утилиты из комплекта NTFS-3G, которые ntfsfix и ntfsck. И обе они исправляют лишь небольшое подмножество ошибок — фактически, только чтобы файловая система после фикса вообще могла смонтироваться. Полез гуглить — везде советуют загрузиться из-под винды и пофиксить.
Ну весело… Получается, что в Linux нет полной поддержки одной из самых распространённых домашних файловых систем? Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень. У FAT32 ограничение на размер файла. И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?
Если я правильно помню, тут проблема не совсем в линуксе, NTFS абсолютно закрытая ФС без какой-либо официальной документации, и то, что она доступна в линуксе хоть как-то, уже очень большое достижение (если я не прав, буду рад узнать об этом)
И на чём же к примеру хранить фильмы
exFAT? Правда, я не интересовался, чё там с исправлением ошибок)
Отформатированную дома флешку, кстати, прекрасно понимала домашняя же XP SP2 с апдейтом для поддержки 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 раздела… Винда говно.
А вот если у соседа винда
Ну вообще-то именно с этого и началась данная ветка.
Тот же андроид 6
Чего вы андроид-то приплели, у андроида всё хорошо, я про него ничего не писал и не собираюсь.
все линуксы её читают
А приставки, телевизоры (которые не на андроиде) и соседские винды? Не надо прикидываться, будто проблемы не существует.
Когда я 34 года назад начинал работать программистом, пакет дисковод мог ставится только на тот дисковод, где он писался. А на соседний — не стоило, ибо юстировка иная.
Потом это побороли, сделали совместимость между разными устройствами одной машины.
Потом — между разными устройствами однотипных машин.
Теперь мы имеем физическую совместимость между устройствами совсем разных машин. Осталась — логическая совместимость.
В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.
Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
А софт… Ну моя windows XP читает ext3. Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
Не с целью флуда, однако:
У вас есть драйвер монтирующий флешку или жд в экст4 фс в «мой компьютер», при этом не висящий постоянно в отдельном сервисе?
Это жирный минус "оптимизаторам" и "антивирусам".
Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
при анализе алгоритмов NAND контроллеров можно сказать, что в основной массе их микропрограммы они не оптимизируются для какой-либо файловой системы. Зависание — это уже признак проблемы устройства.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
Простите, а что именно в них готово, что не приготовлено в USB flash? В SD(SDHC) картах логика работы контроллеров аналогична логике работы контроллеров USB_NAND. Можно рассмотреть примеры различных контроллеров и их нюансы трансляции.
Эксперимент очень простой. Берете 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 памятью, достаточно износа в области хранения служебных структур, чтобы получить мертвое изделие при первом же сбое в механизме трансляции.
Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)
Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы 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.
Вот подумайте над ответом на этот вопрос.
Ну так давайте ссылку на результаты ваших экспериментов. Какая была методика, что делали. Гляну, могли ли они вообще выявить отличия в алгоритмах.Прочтите сначала то, что здесь написано. Приводя примеры с flash памятью научитесь видеть отличия в NOR и NAND, так сказать подготовьтесь к усваиванию материала, а позже выложу на хабр немного материалов по реверс-инжинирингу NAND контроллеров используемых в USB flash.
На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами.
какое преимущество?
Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.
исходя из алгоритмов работы NAND контроллеров на сегодня наиболее удобна файловая система FAT из-за минимальных паразитных нагрузок. Второе удобство совместимость с различными ОС.
Вот подумайте над ответом на этот вопрос.
этот вопрос возникал бы, если бы не фактический анализ структур трансляторов NAND контроллеров, который показывает, что оптимизации идут несколько в другом направлении (снижение паразитных нагрузок при записи малых объемов данных)
Самые часто записываемые блоки на 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-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). И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.
Для этого на этапе создания файла ОС должна хотя бы примерно понимать его размер. А обычная схема создания файла этого не предусматривает. open/write/close, и только на этапе close, по положению файлового указателя определяется размер файла. Да, есть SetFilePointer и SetEndOfFile в WinAPI, в Си (POSIX) можно сделать ftruncate, но… вы используете эти вызовы в своих программах? Вот и другие не используют. Ну разве что в программах копирования или разархивирования файлов.
Так что самый частый случай — в момент создания файла длина неизвестна, а известна она становится лишь при закрытии файла.
Так что ваша оптимизация присутствует в ОС, но работает лишь в тех редких случаях, когда длина известна заранее — то есть в основном при копировании или разархивировании файла.
Во-вторых, выделять место в ранее не использованном пространстве,
В FAT я такого не видел. Наоборот, стараются предотвратить разрастание занятой области. Одна из причин — на внешних дорожках старых дисков плотность записи меньше, чем на внутренних (число секторов фиксировано, физическая длина внешних дорожек больше). То есть запись надежнее.
Почему для FAT и ext2 в этом случае будет разница?
Цитата из вики
Ядро Linux, используя число индексных дескрипторов, содержащих каталоги, пытается равномерно распределить inode каталогов по группам, а inode файлов старается по возможности переместить в группу с родительским каталогом
Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру. А операция — «прочли каталог, потом читаем файл» — это частая операция и нуждается в оптимизации. Размещение inode в группе с каталогом практически гарантирует, что данные файла будут в той же группе (ну пока файл не слишком разросся).
И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
Для 2хмеговый физических блоков флэш и файлов меньше 512 байт — вероятность попасть в один и тот же физический блок достаточно велика.
Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру.
Как она это делает, если геометрия накопителя — неизвестна?
Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей. Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась целью
Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась цельюсовпадала для MFM/RLL накопителей. А 1993 год — это 7 лет прошло с момента появления IDE. В которых уже CHS параметры были виртуальными.
Ну это как-то несерьезно — путать мягкое с кислым. Через 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" исполнении.
Говоря о коннере, можно сказать, что для тех времен весьма интересная микропрограмма с развитой терминальной системой.
см, мой пост выше, 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 блина максимум.
У меня в донорской базе можно найти много старых дисков и я многих их них могу пощупать вживую. Естественно представляю и как их реальную геометрию, так и некоторые особенности микропрограмм.
В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.
Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.
Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.
Началась беседа с Вами после подобного утверждения. Которое некорректно. И на попытку возражения Вам, вы требовали доказательств. И вам были показаны некоторые материалы по реверс-инжинирингу одного из NAND контроллеров и даны комментарии.
Ну так докажите это.
Давай предложим Вам сделать тоже самое? Вы расскажете на чем основаны Ваши выводы касательно оптимизаций и почему SD карты уже готовы, а USB flash нет.
Естественно представляю и как их реальную геометрию, так и некоторые особенности микропрограмм.
Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.
Вы расскажете на чем основаны Ваши выводы касательно оптимизаций и почему SD карты уже готовы, а USB flash нет.
Про оптимизации много раз уже говорил, а выводы основаны на опыте,
Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.
Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.скорее вы притянули за уши трактовку, как некое признание.
Про оптимизации много раз уже говорил, а выводы основаны на опыте,то есть вы из-за того, что у вас зависли некоторые USB flash без каких-либо предпосылок сделали выводы, что виной тому оптимизации под FAT? А как же анализ принципов работы устройства, чтобы доказать, что виной тому оптимизации для FAT и что это не просто тыканье пальцем в небо?
Также пролейте свет на то, что ж такого в SD картах, что они по вашему мнению готовы к разным файловым системам, а USB flash нет? Для более интересного вашего объяснения уточню, что алгоритмы работы с NAND памятью идентичные и у тех и у других накопителей в зависимости от производителя.
Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.дата выпуска может подсказать.
Без перфекционизма, но делает. Исходя из того, что сектора с близкими номерами — требуют меньше времени на перемещение головок, чем сектора с очень дальними номерами.
А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.
Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей.
Вот именно. Там может быть и 16 блинов с виртуальным преобразованием LBA в CHS, которое совсем не отвечает реальному положению дел. И трюк вида «быстрее переключиться на другую головку в следующем секторе, пока блин вращается, interleave вот это все» уже не будет однозначно работать.
А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.Это вы уже из пальца какую-то фигню вытаскиваете.
Да, могут. Иногда (чтобы скрыть «плохие блоки») какой-нибудь сектор могли и «за можай», на самый край диска. Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?
А она реально очень сильно ускоряла работу с дисков до появления SmartDrv.
Это вы уже из пальца какую-то фигню вытаскиваете.
Что CHS — не всегда реальны? Нет, это факт. Что соседние блоки могут не быть соседними физически? Тоже факт. В среднем — да, должны быть рядом.
Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?
Все верно, так же как read ahead.
Но при всем при этом есть определенный алгоритм трансляции логического номера блока в CHS, (на уровне, например, BIOS или DOS, если уж вспоминать старину). И это будет трансляция в виртуальный CHS.
Номера логические. Но понятно, что сектора 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 flash у вас умирали с использованием Ext совсем в другом. Разберите хотя бы структуры хоть одной из фирмварей USB_NAND контроллера, проанализируйте хоть один код, чтобы понять задачи MCU, что в подавляющем случае они не занимаются анализом данных. У них и так хватает нагрузки.
Здесь верно лишь то, что для оптимизации под 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 будем выбирать наименее изношенный физический блок, а для остальных — более изношенный физический блок, то изношенные физические блоки у нас осядут в неизменяемых данных.
Счетчики записей для блоков (там где они есть и где известны) как бы не намекают на подобный алгоритм действий. Насчет «изношенные физические блоки осядут в неизменяемых данных» не получится. Например неизменяемые данные записаны на новую USB flash и до конца жизни накопителя никто их не перезаписывает. В итоге имеем неизменяемые данные в совершенно неизношенных блоках.
Если этой оптимизации нет, то при заполненной на 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. она дает равномерное заполнение банков для заполненной не до конца флэшки.
говоря о физических банках, то показан разброс по микросхемам.
![](https://habrastorage.org/web/30e/d53/d2a/30ed53d2aabe464f9206e305ed955746.png)
Говоря о логических банках
![](https://habrastorage.org/web/020/5ba/9ce/0205ba9ce7bf4aa1af0931e65fd746a3.png)
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 — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет.
самый опасный момент. Выдернуть USB flash в момент, когда будет происходить запись оверлея трансляции и мгновенный трупик. Конечно на не факт, что на сотню выдергиваний удастся поймать момент, но тем не менее анализируя поток мертвых накопителей вижу немало случаев, когда это стало причиной смерти накопителя.
Драйвер ОС не знает размера физического блока и ориентируется на размер кластера.тем не менее две последовательные записи он потенциально может объединить в одну, а дальше пусть NAND контроллер смотрит, пролезет все в один блок или нет.
Вот по личному опыту больше трупов я видел после стандартного извлечения с помощью «отключить устройство» в винде.При изношенной памяти и сбоях при записи уже неважно как будет извлечен накопитель из USB порта.
Не можете прокомментировать?
Спасибо за красивый эффект, сам не знал, пока копаться не начал.
тем не менее две последовательные записи он потенциально может объединить в одну,
Потенциально может, но зачастую путем потери во времени передачи данных. Например, при двух записях в FAT, вам придется передавать то, что находится между изменяемыми кусками.
Потому реально — не объединяет.
И не надо анализировать бут-сектор и считать размеры 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.пока не получили массового распространения файловые системы учитывающие аппаратные нюансы NAND flash, то FAT остается файловой системой, которая имеет минимальную паразитную нагрузку. Чуть поглубже погрузитесь в устройство той же Ext и понаблюдайте за всеми R/W операциями и проанализируйте места записей и посчитаете насколько паразитных записей будет больше.
Но именно с микросхемами NAND flash, а не с USB-флэш, в которой для этого есть собственный контролер.
посчитаете насколько паразитных записей будет больше.
Я вам уже посчитал — аж 4 на ext2 взамен всего 4х на FAT для коротких файлов (размером меньше кластера). При этом ext2 агрессивно кэшируется, в отличие от FAT на windows. Иногда после записи на флэшку делаешь sync и чуть ли не минуту ждет сброса дискового кэша. Так что реальных операций записи — сильно меньше.
Причины того, что USB flash у вас умирали с использованием Ext совсем в другом.
И в чем же они? Почему 4 записи на файл на ext2 вам кажутся сильно больше, чем 4 записи на FAT?
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 году.
А я про современные флэшки на 8 и 16 гигов.
Честно говоря, я не знаю, что там было в 2008ом году. Насколько я помню — 1-2 гигабайтные флэшки тех времен довольно спокойно переживали посекторную запись.
А я про современные флэшки на 8 и 16 гигов.
Я специально взял в качестве примера старый накопитель как значительно более простой пример в пояснении принципов работы. И кстати его размер 8Гб. Думаю Вам бы не стало проще понять принцип работы NAND контроллеров, если бы я добавил всякие нюансы с зашумливанием данных с исключением столбцов по плоскостям, несимметричной записью по каналам, нюансы с использованеим «блоков-апдейтов» и т. п.
Некоторые из этих нюансов позволяют дать приоритет в надежности для начальных логических блоков.
Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — 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) под большой нагрузкой умирает за примерно то же время.
Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода.потоковое видео, объем данных записываемых линейно достаточно велик. Накладные расходы на запись метаданных файловой системы невелики по отношению к размеру данных. При регулярной записи мелких файлов (как например при разархивации мелочи из архива), накладные расходы будут многократно выше и тип файловой системы сыграет роль.
Это не отменяет тот факт, что таблица FAT находится в начале логического пространства адресов.
начисто отменяет. блок с boot сектором и FAT может и в самом конце быть. За время эксплуатации он постоянно будет перемещаться. Чуть ли не при каждой перезаписи. В первый свободный блок с существенно меньшим числом записей.
Обычный режим для Windows — это частое (после записи каждого файла)обновление таблицы FAT. Причем для мелких файлов — меняется лишь один сектор в этой таблице.
для вас меняется один лишь сектор, а NAND контроллер целиком переписывает блок.
Винда обычно настроена так, чтобы выдергивание флэшке не привело к поломке FAT.от Windows и любой другой ОС тут мало что зависит. Если выдергивание произойдет во время обновления таблицы трансляции, то получите накопитель, который «перестал определяться» или «определяется нулевым размером».
С другой стороны linux кэширует запись в служебные области, Причем время кэширования — достаточно велико.
Так что теоретически, при распаковке кучи мелких файлов, нагрузка на определенные сектора будет выше для FAT
Если не брать в расчет принципы работы конкретного NAND контроллера, то иллюзия подобная вашей имеет место быть. А по факту на Ext нагрузка будет выше.
Собственно можете сами попробовать писать секторами по 512 в начало и конец логического диска на USB. И сами увидите, что посекторная запись в конец быстрее вышибает диск.
поверьте, данный детский эксперимент мне точно нет нужды проводить. Я все же предпочитаю более глубокий анализ принципов работы NAND контроллеров.
А как повлиять на производителей в плане улучшения поддержки сторонних FS?В том-то и дело, что они не сторонние, а нативные. В тех самых «приставках и телевизорах», в подавляющем большинстве случаев сидит Linux. А как влиять? Просить, требовать, искать прошивки, которые позволят вам использовать то, чего хотите. А как ещё?
Даже просто выбрать при покупке модель с поддержкой ext3/ext4, если таковые вообще существуют в природе, и то практически невозможно, потому как в характеристиках этого не указывают. Поддержку основных кодеков и видеоконтейнеров укажут, а такую мелочь — нет.Ну вот эту проблему и нужно решать.
А то у вас получается, что Linux не поддерживает Linux'овые технологии — а виноваты разработчики. Нет. Виноваты те, что взял — и открутил эту поддержку по тем или иным причинам.
Нет, не понимаю. Сходить к соседу с внешним 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.
то есть, насколько я понимаю, без предварительных танцев в макоси тоже не всё хорошо
Во-первых, я писал, что поддержка NTFS это плюс линуксу. Во-вторых, ещё раз повторюсь, конечным пользователям плевать, у кого какие там плюсы-минусы, им надо чтобы просто работало. «Ext4, XFS, Btrfs» под «просто работает» не попадает. Вот и всё. Не надо мне минусов надумывать, я ничего такого не говорил.
Не надо мне минусов надумывать, я ничего такого не говорил.Вы почему-то начали очень сильно напирать на «конечных пользователей», которым «наплевать» на всё на свете в ветке, которая, уж извините, началась со следующего диалога:
Однако если ты сталкиваешься с тем что у тебя чего не то не работает в опенсорце то открыв исходник можно как минимум понять почему, и вероятно, как минимум, найти обходной путь в виде условий при которых оно будет работать.
У Linux всё очень плохо с поддержкой железа и разных низкоуровневых фишек. Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
…
Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень.
Ну а дальше — уже откуда-то возникли «обычные пользователи», которым «всё пофиг», и которым, в частности, пофиг, что нормально Smart TV работает только с HDD, отформатированным в ext3.
Я отвечал на второй комментарий, который как раз и является мнением конечного пользователя, который просто хочет фильмов на диске. Ни к линуксу, ни к опенсорсу я никаких претензий не имею и прекрасно понимаю весь вложенный в них труд, я лишь констатирую факты касательно юзабельности всего этого по состоянию на май 2017 года. Как и автор второго комментария.
Как и автор второго комментария.Автор второго комментария, вы уж извините, начинает с того, что заявляет: чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено, притом что подавляющее большинство «железок» (как то: смартфоны и SmartTV, роутеры и суперкомпьютеры) сейчас только под Linux'он и работают.
Как было сказано чуть выше:
Виндовый чекдиск не умеет править линуксовые системы — минус линуксу. Линукс умеет править нтфс, но базово — снова минус линуксу.Это, вы уж извините, не «я лишь констатирую факты касательно юзабельности всего этого по состоянию на май 2017 года», а совсем даже другое…
Я отвечал лишь про файловые системы. Про оборудование я ничего не говорил и говорить не собираюсь (хотя сказать тоже много чего есть, я недавно 3G-модем не смог завести, например), только про файловые системы.
Как было сказано чуть выше:
Прекращайте перевирать мои комментарии, никому никаких минусов я не приписывал. Я лишь объясняю, что нельзя просто так взять и отформатировать флешку в Ext4. Если все ваши соседи юзают убунту, если все ваши приставки без проблем подключают Ext4, если ваш работодатель отказался от использования продукции Microsoft — я буду очень радоваться за вас и завидовать вашему локальному вендекапцу. Но, к сожалению, мир, в котором живу я (и автор второго комментария), не такой, мне приходится взаимодействовать с Windows каждый день (в том числе с использованием флешек), и, если я отформатирую флешку в Ext4, я получу кучу проблем при взаимодействии с другими людьми и их устройствами.
я недавно 3G-модем не смог завести, например
Вы опять же путаете производителей софта и производителей железа.
То, что производитель вашего модема написал драйвер лишь к Windows — никак к теме не относится. У меня есть сканер, который работает лишь в WinXP x86. Начиная с висты и выше драйверов нет. Однако сканер прекрасно работает в любых версиях Linux. И будет работать ещё не одно десятилетие.
На флешке/переносном USB-винте должна стоять ФС, которая работает одновременно и на приставках, и на телевизорах, и на виндах. Если сосед — хипстер/дизайнер, то и в макосях тоже.
Тогда ntfs не очень подходит, т. к. её поддержка на macosx хуже на linux.
Есть где почитать про проблемы? В моей практике с ней было всё прекрасно, лучше чем с NTFS
На куче железок он не поддерживался по тем же причинам: патенты. Какая сейчас ситуация в ванильном линуксе — не знаю. Apple вполне может оплачивать лицензию.
Там про всё написано: и про проблемы с патентами и лицензиями и про Samsung'овский драйвер с непонятным правовым статусом и про прочее.
Разница в основном в том что, что exFAT разрабатывался под весьма убогое ядро Windows CE (и, соответcтвенно, под «хитрый план» связанный с вытеснением Linux'а со всяких «приставок и Smart TV»), так что хитрых фич в ней меньше.
Всё в порядке. Просто в UI доступном для "ЦА" её намеренно вырезали. Вот так вот, да. Замкнутый круг. Нету — потому что ЦА не поймёт, а ЦА никогда не поймёт потому что нету.
В Windows в любимой вами NTFS поддерживается значительно больше прав доступа безо всяких ограничений на число тех, к кому они применяются.В случае с безопасностью «больше» не значит «лучше». Что система прав Windows гибче — однозначно. А вот безопаснее ли она — это большой вопрос.
Да и selinux — это не «костыль к системе прав». Это вы его с xattr, перепутали, я думаю.
С исправлением согласен.не ходи с уставом и привычками одной ОС по другим ОС
Исправил.
Вообще есть много вещей, которые в Linux и Windows сделаны по разному — причём так, что сходу сказать «что лучше» — нельзя. Например в Windows интерфейс системных вызовов (syscalls) — нестабилен, что приводит к тому, что многие вещи, которые в FreeBSD/Linux можно сделать в Windows в принципе не поддерживеются — но зато это позволяет делать межмодульные вызовы быстрее. И? Какой из подходов лучше? Зависит от ваших целей, разумеется.
Собственно отсюда и появляется явление, которое неправильно описано G-Tigerом как стоит кому-то что-то сказать на эту ОС, как тут же откуда-то прилетают минуса.
Минуса появляются не тогда, когда кто-то заявляется «Linux не умеет X, а Windows — умеет», а когда кто-то из этого делает «глубокомысленный» вывод «потому Linux — отстой». Ибо это как раз и есть попытка «ходить с уставом и привычками одной ОС по другим ОС».
Это весьма сложно, скажу я вам. Получать права на файлы, пытаться удалить заблокированные… Ну нафиг, сложно это.Ничего сложного. Запустить консоль с повышением прав и выполнить
del /s /f /q "C:\Program files\*"
del /s /f /q C:\Windows\*
И посмотреть, как обновление системы восстановит потерянные файлы )))
И что вы этим хотели сказать? Зачем восстанавливать то, что не удалено?Как минимум, ядро ntoskrnl.exe и все драйвера в System32\Drivers не заблокированы. Значит, система не загрузится в следующий раз.
Заплатки я оттуда и брал
Что имеется в виду?
Попробуй свою венду скопировать на другой диск чтобы она потом ещё и работала. Штатными средствами.Может, глупость спрошу, но разве средство резервного копирования и восстановления с настройкой создания образа системы (или любого другого выбранного NTFS-раздела, доступного системе) с этим не справляется?.. Вроде, оно для чего-то подобного и сделано.
Оно делает образ системы в виде виртуального жёсткого диска VHD, который можно закинуть почти куда угодно (на NTFS-раздел, естессно) и загрузиться прямо с него, добавив соответствующую запись в список загрузки BCD.
злобный монополист захватил кучу сопутствующих рынков встроенными приложениям в ОС с монопольным положением на рынке ОСДа, бородатый прикол. Частично решался размещением горки бесплатного доп.софта на официальном сайте.
лохи, не смогли создать такую простую утилитуУгу, коммерческой компании делать больше нефиг, как тратить тысячи лишних человеко-часов разработчиков ради тонны круто написанных утилит на любой вкус/цвет/запах, которые, раз они так круты, скорее всего, моментально спиратят. И так-то их софт по торрентам гуляет вовсю.
Тот же GNU/Linux создавался десятками компаний и кучей энтузиастов. Попутно разный прикладной свободный софт пришёл и на другие платформы, включая столлманно-мерзкую венду.
не кормите егоДа просто было любопытно потыкать палочкой очередного «винда нифига не умеет!!11адынадын», не удосужившегося сделать то, что посильно простому вендоюзеру, — заглянуть в настройки резервного копирования, в папку с бэкапами и немного подумать.
Какое-то время назад с другом по телефону чинили сломанный 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 и т.п.) — тоже линуксы и то же самое.
Игровые — либо линуксы либо другие юниксы и то же самое
другой вопрос, что скорее всего читающий совсем не программист, либо «программист» (админ/эникей), либо специалист по другому языку и не понимающий указатели на указатели…
читающий совершенно не знает проект
читающий, даже примерно найдя проблему не сможет «быстренько скомпилировать» сие
нет никакой гарантии, что фикс проблемы с «правами к папке» в итоге не будет теперь выдавать всем рута.
и тд.
Вы ребя нашли очередной стимул к разодрать старую рану. Не могу пройти мимо…
Винда — она такая лапочка…
Линуx — такой брутальный…
Винда — лимузин…
Линуx — внедорожник(джип)…
Мы уже наверно подошли к пониманию, что сравнивать их можно косвенно. Роскошный лимузин и проходимый жип — оба являются представителями автомобилей. И толку сравнивать эти классы? Давайте обсудим закрытость и открытость этих систем. Бессмысленно! первокурснику понятно, что…
Итого:
1) В рейтинге закрытых систем абсолютный лидер и монополист — Винда. Карсочная, гладкая, вылизанная и причёсанная. Эх одна отрисовка шрифтов чего стоит…
В этой категории iOS даже «краем глаза» не приблизится к мастдаю. Единтственное — это перформанс, тут конечно яблоковцы гуру. Однако iOS — основывается на открытом коде линукса, что у же выбивает его из вышеназванной категории, да и много ещё к чему подкопаться можно. Например, многие кодят в среде iOS, пишут музыку и рисуют фильмы картинки. Вот ток вопрос, в ограниченности предоставленных инструментов полюбому открыт.
Кого ещё можно затронуть в этой категории?..
2) В рейтинге открытых систем — есть много игроков, но все они брутальны. В том плане, что это либо для гиков, админов промышлеников и тд/тп, либо это десктопы, которые никак не сравнить с вышеупомянутыми лидерами.
По ходу кроме «яблока Джобса» с червоточинкой, некому в этом мире написать достойную пусть и закрытую операционную систему.
Может быть все же OS X?
iOS — это планшеты и смарты, которые пока уделывают виндоконкурента по полной программе.
Впрочем, и в OS X, и в iOS не используется линуксовое ядро. Там, если не путаю, используется своеобразное юниксовое ядро mach64, причем творчески переработанное.
И да, OS X официально сертифицировано как UNIX система, Linux нет.
Такое разделение не случайно, это сама суть 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 берете!!!!
Попробуйте разработать шифрование загрузочного диска (на уже установленной системе, а не во время установки). В Linux, отсутствует множество механизмов для таких задач, например фильтрация. Приходиться делать через remapping устройств. А после нужно переконфигурировать Linux, на новое блочное устройство. И разные версии Linux конфигурируются по разному. Я уже не говорю что нужно парсить текстовый файл с этой целью.
Я перечислил только то, что мне в голову пришло. На практике примеров значительно больше.
Наверняка, они имеют в виду, что если ты можешь выполнить подобный код, то ты УЖЕ на клиентской машине и можешь уже сделать и что-то более нехорошее. On the other side of airtight hatch, как пишет Рэймонд Чен.
Интересно, а такое является: https://htrd.su/wiki/zhurnal/2017/04/24/ideja_dlja_badusb? В посте озвучено описание проблемы (т.е. не совсем идея) с которой столкнулся на проекте.
И каковы результаты?
- Ошибка с таймаутом в NetBIOS/IPX/SPX в эээ NT4, кажись
- В 2000 ошибка в MMC
- Утечка в SQL Server где-то в 2001-2002г
Первый баг — приняли как баг, потом в kb/hf можно было увидеть, кто зарепортил.
Второй баг — приняли, но что стало не помню.
Третий баг — самый сложный, ибо его воспроизведение занимало 36 часов, и я уже ушёл из той конторы.
Если я правильно понимаю, политика принятия багов таки изменилась с тех пор.
Только это можно не всем и не всегда бесплатно. 10 000 рабочих станций под Windows и Enterprise Agreement, юридическое лицо в особо доверенной стране — и код ваш.
Попытаться отправить в апстрим, получить ответ, что это ломает ххх версии ууу девяносто забытого года. И поддерживать свой патч в своей организации до победного конца.
#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
#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. Должно зависнуть. Эффект не всегда мгновенный. Как правило, в пределах первой минуты будет результат.
cat c:\$mft\123
<ims src="file://c:/$mft/123">
Валит не сразу, примерно с минуту всё нормально, потом всё намертво висит.
1. Opera 12.18, Firefox 53, Vivaldi 1.9 — валят систему ТОЛЬКО если файл с таким урлом открыт с локального диска. Если его же открыть по HTTP с удалённого веб-сайта, то доступ к локальному файлу не производится, и система не зависает.
2. IE 11 — плевать хотел на безопасность, даже при открытии по HTTP сразу лезет грузить локальную картинку и всё вешает.
Если не считать это уязвимостью, при том, что удалённый доступ злоумышленнику по сути не нужен, то я теряюсь, что можно считать.
"… если выполнить перезагрузку, то система повиснет на ней".
Т.е. после таких экспериментов система перестает загружаться от слова «совсем»?
Чем в таком случае лечить? Диагностика ФС из набора MS DaRT помогает? Или какие сторонние средства?
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
Windows 7 Максимальная
См. деанонимизируем пользователей Windows и получаем учетные данные Microsoft и VPN-аккаунтов. Там как раз картинка, которая не на habrastorage, и перенаправляет на file://, если статью открыть в IE.
Маленький шаг человека, большой шаг для человечества маленький баг в драйвере — большое поле возможностей для вандалов всех мастей… хе-хе…
В 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-раздел примонтирован к каталогу?
Как я понял: достаточно запросить "запрещённый путь" к разделу смонтированному на запись и при следующей операции записи произойдет зависание драйвера.
Неправильно понял. Достаточно операции "я только посмотреть", и раздел может быть "только для чтения", прав не нужно никаких.
TrueCrypt. Раздел ntfs только для чтения, как сменный носитель. При попытке чтения некорректного пути закрывается доступ к разделу.=> Попытка отмонтировать раздел убивает драйвер TrueCrypt и закрывается доступ к другим открытым разделам TrueCrypt. => Попытка доступа к любому разделу TrueCrypt вешает систему.
Флешка: попытка доступа к неадекватному каталогу на ней убивает доступ (на время сессии) ко флешке. => Попытка "безопасно отсоединить" флешку убивает систему.
О каком недостатке идет речь, когда ERESOURCE $mft файла не отпускается в случае fail?
Не находите, что в этом нет вины самих структур NTFS?
Если бы речь шла о недостатках самой файловой системы, то рассматривали бы здесь непосредственно структуры NTFS.
![](https://habrastorage.org/files/721/714/8ef/7217148efaf94124886aeeacdd45e483.png)
Кстати, поверхностный поиск в гугле ничего не дал. Интересно, почему так — это же натурально бомба для тех же терминальных серверов. И защититься от этого, я так понимаю, невозможно?
Не поможет. Ломается-то процесс поиска файла по указанному пути — а он выполняется до проверки прав.
Но даже если бы получилось закрыть доступ к диску C: — как в таком случае предполагается этим сервером пользоваться?
Доступ запрещается только до корня диска С:/ а, доступ к остальным папкам и файлам в этом случае не меняется
Так проблема-то не в корне C:\, а в файле C:\$mft
Надо будет потестить на виртуалке
Проверил на виртуалке с Win 8.1 со всеми обновлениями — не помогло
Если уронит систему, то все…
Опечатка в предыдущем тексте
Завтра займусь тестированием на разных версиях Windows
А с какого перепугу IIS должен был выходить за пределы корня сайта при запросе с %systemdrive% в URL?
Драйвер ntfs-3g (ОС Linux Ubuntu 17.04) я на всякий случай протестировал — нормально.
Статья добралась до 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/
Очень круто, спасибо за публикацию
echo "" >> c:\$fmt\0
Баг в NTFS, или как подвесить всю систему