Баг в NTFS, или как подвесить всю систему

    Не так давно при разработке фильтра файловых систем возникла проблема, которая приводила к подвисанию всей системы. Казалось бы, фильтр выполнял очень простые действия и сам был очень примитивным. Чтобы выяснить причину, пришлось спуститься до отладки и реверс-инжиниринга драйвера NTFS. Анализ выявил очень интересный эффект. Если скомпилировать и выполнить очень простую программу, изображенную на рисунке ниже, то доступ к соответствующему тому подвиснет.


    Т.е. в данном примере, если попытаться открыть любой файл относительно файла $mft, доступ ко всему тому «С» повиснет, а так как этот том является системным, подвиснет и вся система. При этом не нужно иметь каких-либо прав. Если же том был не системным, то повиснет только доступ к этому тому, но если выполнить перезагрузку, то система повиснет на ней.

    Немного теории


    Прежде чем описать суть проблемы, стоит рассмотреть базовые принципы построения файловых систем. Когда некий процесс открывает файл, кроме полученного HANDLE на него, в пространстве ядра также формируются структуры, как самим ядром, так и файловой системой, которые, по сути, представляют файл тома в памяти. Ниже на рисунке изображены эти структуры.


    HANDLE файла всегда ссылается на структуру ядра FILE_OBJECT. Эта структура формируется ядром перед посылкой запроса файловой системе. Файловая система, в свою очередь, инициализирует поля этой структуры. Таким образом, структура FILE_OBJECT будет содержать указатели на структуры файловой системы: FCB (File control block, содержит все необходимые данные для управления файлом) и CCB (Context Control Block, содержит данные, уникальные для конкретного открытого экземпляра). Также не исключено, что два разных HANDLE будут ссылаться на один и тот же файл тома, как это отражено слева. Структура FCB содержит список всех структур CCB. Структура CCB содержит указатель на соответствующую FCB. Т.е. для каждого открытого файла тома в памяти будет ровно одна структура FCB. Если файл открыт несколько раз, то также будет сформировано ровно столько CCB структур, сколько раз был открыт соответствующий файл, и все эти структуры будут ссылаться на единственную FCB структуру.

    Поскольку доступ к файлу может выполняться одновременно разными или одним и тем же процессом, то эти параллельные операции должны быть сериализованы. При этом допустимо, что некоторые операции будут выполняться одновременно (например, чтение), однако существуют ситуации, когда доступ должен выполняться монопольно (например, запись). Для этого ядро предоставляет механизм сериализации – ERESOURCE. Этот объект может быть захвачен как монопольно, так и разделяемо. Если объект захвачен монопольно, тогда любые попытки захватить его встанут в очередь ожидания. Если объект захвачен разделяемо, тогда попытки также захватить его разделяемо будут удовлетворены немедленно. Если же объект захвачен разделяемо и очередь ожидания не пуста (т.е. была попытка монопольного захвата), тогда любые попытки захватить его встанут в очередь ожидания.

    Структуры FCB файловых систем для сериализации доступа содержат эти механизмы и активно пользуются ими во время доступа к файлу. Таким образом обеспечивается целостность файла как в памяти, так и на томе.

    Файл $mft файловой системы NTFS является системным. Этот файл описывает расположение всех файлов на томе. NTFS при монтировании открывает его для личного использования. При попытке прочитать содержимое директории или во время открытия файла NTFS выполнит чтение файла $mft. При любой попытке удалить файл или создать файл NTFS выполнит запись в этот файл. Следовательно, перед любой такой операцией механизм ERESOURCE этого файла также будет захвачен, затем будет выполнена сама операция, после чего механизм будет освобожден.

    Функция NtfsCommonCreate


    Чтобы понять суть проблемы, необходимо понимать принцип работы функции NtfsCommonCreate файловой системы NTFS. Очень упрощенный псевдокод изображен ниже на рисунке. Приведены только те части функции, которые имеют прямое отношение к проблеме.


    Файловая система NTFS хранит дерево уже открытых файлов/директорий. Поэтому целесообразно в целях повышения производительности найти целевой файл в этом дереве вместо многократного чтения тома. Следовательно, функция посредством функции NtfsFindStartingNode попытается найти его. Если же найти файл не удалось, тогда функция попытается найти директорию, в которой он располагается. Эта попытка будет выполняться вплоть до корня файловой системы. Функция NtfsFindStartingNode возвращает указатель на структуру FCB либо самого файла, либо той директории, которая по глубине ближе всех располагается к целевому файлу. Функция также вернет часть необработанного пути относительно найденной директории. Также функция предварительно захватывает ERESOURCE найденной директории или файла разделяемо.

    Далее функция NtfsCommonCreate проверяет, есть ли часть необработанного пути, если нет — значит функция NtfsFindStartingNode нашла сам файл, и в таком случае работа функции NtfsCommonCreate завершается. В противном случае функция продолжает поиск файла, но уже на томе.

    Как видно из псевдокода, функция содержит цикл, в котором последовательно открываются директории, ведущие к файлу. В начале работы цикла проверяется, является ли файл директорией, и если нет, тогда работа функции завершается с ошибкой. В противном случае извлекается следующее имя в пути и выполняется попытка открыть файл/директорию с таким именем посредством функции NtfsOpenSubdirectory. Функция NtfsOpenSubdirectory также захватывает открытый файл/директорию монопольно. Перед вызовом функции NtfsOpenSubdirectory также освобождается предыдущая открытая директория функцией NtfsOpenSubdirectory. Работа цикла будет продолжаться до директории, в которой будет располагаться предполагаемый файл.

    По окончании своей работы в случае неуспешного завершения функция NtfsCommonCreate закроет последнюю найденную директорию посредством функции NtfsTeardownStructures. Также эта функция освободит ERESOURCE директории/файла, если это возможно. Т.е. если эта директория/файл не являются открытыми. Т.к. эта директория/файл были открыты файловой системой только что, вероятнее всего, что их ERESOURCE будет освобожден, а FCB файла будет закрыт.

    Суть проблемы


    Когда будет произведена попытка открыть файл относительно файла $mft, функция NtfsFindStartingNode не найдет его, т.к. эта функция выполняет поиск несколько иначе, в отличие от функции NtfsOpenSubdirectory, которая находит этот файл всегда. Следовательно, начнет работу цикл, начиная с корня файловой системы. Далее функция NtfsOpenSubdirectory откроет этот файл и захватит его ERESOURCE монопольно. На следующей итерации цикл обнаружит, что файл не является директорией, и, следовательно, прервет свою работу с ошибкой. А при завершении своей работы функция NtfsCommonCreate посредством функции NtfsTeardownStructures попытается закрыть его. Функция NtfsTeardownStructures, в свою очередь, столкнется с тем, что она не сможет закрыть файл, т.к. он открывается самой файловой системой при монтировании. При этом, вопреки ожиданиям функции NtfsCommonCreate, функция NtfsTeardownStructures не освободит ERESOURCE $mft файла. Таким образом, он останется захваченным навсегда. Поэтому, например, при попытке создания файла или чтения файлов тома, файловая система NTFS попытается захватить ERESOURCE $mft файла и зависнет на этом этапе навсегда.

    Заключение


    Данную проблему нельзя назвать уязвимостью, но имея удаленный доступ к машине, возможно нарушить ее работу. Данная ошибка сохраняется вплоть до последних версий Windows, за исключением последних обновлений, начиная как минимум с Windows Vista. Как уже упоминалось, описание работы файловой системы NTFS в этом случае является очень упрощенным и отражает только саму суть проблемы. В действительности реализация намного сложнее приведенного описания.
    Аладдин Р.Д. 91,20
    Информационная безопасность
    Поделиться публикацией
    Комментарии 459
    • +4
      Пусть простит меня сообщество за холиварную тему, но все-таки…

      Вопрос открытых или не открытых исходных кодов ОС — это вещь первостепенная. Сколько литров кофе потратили сотрудники компании во время реверс-инжиниринга, сколько нервных клеток пало в неравной борьбе с плохо протестированным кодом? И все равно пофиксить эту уязвимость типа «отказ в обслуживании» своими силами нельзя — исходников нет, и даже если написать свой фильтр-драйвер и проверять все вызовы NtCreateFile, то для такого драйвера нужна подпись Майкрософт, а она есть не у всех.

      Если бы исходники были открыты, достаточно было бы взять отладчик, поставить брейкпоинт, заменить пару строчек, пересобрать модуль и готово.
      • +15
        В теории да. На практике мы имеем дело с тем, что проекты с открытым исходным кодом часто содержат ошибки, которые опытный разработчик никогда не допустит. Например, также имею опыт и с Linux. Для серверов и построения устройств на его базе — незаменимая вещь. Для desktop решений, говоря примитивно, ад. Т.к. сильно не хватает механизмов, которые есть в Windows. Везде есть как плюсы, так и минусы. Не соглашусь с тем, что однозначно можно утверждать, что открытые исходные коды, явный плюс.
        • +18
          проекты с открытым исходным кодом часто содержат ошибки, которые опытный разработчик никогда не допустит

          В проприетарном ПО всё то же самое, только мы этого не видим, потому что код закрытый, ваш кэп :)


          А неготовность линукса для десктопа связана не с открытостью, а с бесплатностью (даже какому-нибудь каноникалу не хватает ресурсов, в первую очередь денег на программистов, чтоб исправить всё и сразу) (хотя можно сказать, что бесплатность это следствие открытости, но вроде не всё так просто)

          • +2
            Не видим, но есть ряд косвенных признаков. Также, теперь можно ознакомиться с WRK v1.2. И попытаться сравнить. Дело не только в отсутствии механизмов, но еще в том, что если они присутствуют, какое у них качество.
            • 0
              Кроме того, исходники минимум двух версий утекли в сеть. За WRK — плюс.
              • 0
                Эти исходники весьма неполные, если что.
                • 0
                  Одной из версий — да.
                  • 0
                    Да вроде обоих. NT4 ещё со скрипом компилируют, дописав пачку кода, а вот W2000 уже никак, не хватает пары подсистем.
                    • 0
                      А, ну как посмотреть, да. Я имел в виду, что кода достаточно для понимания, как что работает.
          • +5
            Но я ведь и не писал, что Linux лучше Widows и не сравнивал функционал. Я писал, что продукты с открытым кодом имеют преимущества перед закрытыми, когда речь идет о быстром исправлении ошибок малой командой разработчиков.
            • +5
              Я их тоже не сравнивал. Как я говорил, и там и там есть как плюсы, так и минусы. На счет преимущества, как показывает практика, это не добавляет скорости разработки. Опять же, от случаю к случаю. Важно понимать что все мы имеем в той или иной степени, разный опыт. И в первую очередь я рассказываю о своем.
              • +1
                > Я писал, что продукты с открытым кодом имеют преимущества перед закрытыми, когда речь идет о быстром исправлении ошибок малой командой разработчиков.

                Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте».
                • +13
                  Некоторые баги в открытом ПО висят десятилетиями… В винде не лучше, но в свободном ПО очень часто бывает «вам надо — вы и делайте»

                  Эта позиция всё же оказывается чуть лучше и понятнее чем "вам надо — ждите, держитесь там и всё такое".


                  Всё же разработчик open source решения ничего не должен конечному пользователю (хотя и с коммерческими, если почитать лицензию, ситуация примерно такая же, но вы ещё и деньги платите). Но хотя бы есть шанс, что если проблема задевает не только вас, то кто-нибудь когда-нибудь может её решить. Или можно кому-нибудь заплатить за решение этой проблемы, как вариант.

                  • +4
                    Я с вами соглашусь. Просто хотел сказать что открытый код != гарантированное исправление ошибок.
                    • +2

                      Зато открытый код — наличие возможности У ВАС ЛИЧНО при наличии навыков исправить проблему "здесь и сейчас".


                      Вот возьмём две ситуации:
                      Slack и Telegram.


                      В первом меня очень расстраивал баг, заключавшийся в том, что при нажатии Alt+Shift открывалось меню (Alt) и выбирался фиг пойми какой пункт (или, рандомно, никакой, но при быстром машинальном переключении раскладки во время печати, когда успеваешь напечатать полтора слова прежде, чем от глаз к рукам поступит сигнал о том, что на экране что-то не то, какая-то "буква" нет-нет, да и матчила какой-то из биндингов в меню и активировала чёрт-те что.


                      Т.к. код у их приложения закрытый (не смотря на то, что это всего лишь кастрированный хромиум с парой кастомных js-скриптов), всё, что мне оставалось после репорта — это ждать пару десятков версий, пока наконец соизволили починить...


                      Во втором меня очень расстраивало что в широкоэкранной (да и в неширокоэкранной тоже, но в этой особенно) разметке балуны (не знаю, как правильно эти прямоугольники по-русски назвать) с текстом имеют слишком маленький лимит ширины и в итоге любой большой текст (особенно вставляемый код) превращается в кашу.
                      И разработчики вот уже год как игнорируют тонны багов и даже закрыли пуллреквест с патчем, исправляющим это (и он уже протух относительно кода).
                      Но… Т.к. код открыт — ничто не помешало мне по мотивом протухшего пулл-реквеста сделать свой патч и добиться желаемого эффекта: текст перестал искусственно сжиматься по горизонтали якобы для улучшения читаемости (чьей, интересно? явно не моей!).


                      Или, опять же, 2Gis против всё того же телеграма.
                      Оба патчат Qt5 для того чтобы собрать своё приложение (ну, нравится людям, видимо, патчить инструменты).
                      Но у 2Gis код закрыт и поэтому остаётся только страдать и иметь не работающее под линуксами отличными от Ubuntu приложение (потому что кроме ситуации с патченными Qt5 и крахом из-за отсутствия использованных костылей в системной версии, они ещё и слинковали бинарник одновременно с двумя версиями ICU).


                      Телеграмовцы тоже любители пропатчить Qt, но… код у них открытый и поэтому это позволило мне (и представителям других дистрибутивов) написать набор патчей для отвязывания его от необходимости как патчить системные Qt, так и билдить свою статическую копию.


                      В случае с 2Gis же… Я уже года два-три, если не больше, репорчу-репорчу, но т.к. Linux не ЦА-платформа — nobody cares.


                      Так и живём :)

                      • +2
                        > Зато открытый код — наличие возможности У ВАС ЛИЧНО при наличии навыков исправить проблему «здесь и сейчас».

                        >… при наличии навыков…

                        Я действительно рад что у вас навыки для исправления багов, к сожалению моих навыков программирования (веб + МК) хватает только для того чтоб написать багрепорты и ждать у моря погоды, что в линуксе что в винде.
                        • 0
                          В случае с 2Gis же… Я уже года два-три, если не больше, репорчу-репорчу, но т.к. Linux не ЦА-платформа — nobody cares.

                          Они, видимо, решили вообще уйти в онлайн и на мобильные платформы (их очередной ответ в вк группе)
                      • +2
                        есть шанс, что если проблема задевает не только вас, то кто-нибудь когда-нибудь может её решить
                        Это верно и для открытого и для закрытого кода. Причём, вероятность иногда выше в проектах с закрытым исходным кодом — баги фиксятся чаще, тестирование осуществляется лучше и так далее.
                        • +3

                          Виной всему деньги и только лишь они. А вовсе не состояние открытости кода и/или лицензии :)

                    • +1
                      Исправление ошибок в системе с открытыми исходниками тоже может быть осложнено лицензией, прямо запрещающей модификацию кода не автору, или требованием подписи новособранных бинарников.
                      Конечно, можно отослать патч правообладателю, чтобы он учел его в следующей версии. Это уже плюс.
                      Но если автор забил на продукт, то ограниченная лицензия на продукт с открытыми исходниками может существенно осложнить возможность исправления ошибки.

                      Короче, открытые исходники — это хорошо в плане исправления ошибок (если исходников нет, то даже «надо — сделай сам» сильно осложнено необходимостью реверс-инженеринга и, частенько, необходимостью сертификации получившегося результата), но совсем не панацея.
                      • +1
                        Исправление ошибок в системе с открытыми исходниками тоже может быть осложнено лицензией, прямо запрещающей модификацию кода не автору
                        Если лицензия позволяет править исходники только автору, то это — не система с открытыми исходниками. Microsoft для таких случаем использует термин shared source
                        • 0
                          Касательно РФ, закон позволяет вносить изменения в программу, которые исправляют баги или адаптируют её для конкретного применения. Главное не распространять изменённую копию. И закон имеет приоритет над лицензионным соглашением.
                          • +1
                            Закон мог бы иметь приоритет, но… не имеет. Дело в том, что в соответствующий пункт несколько лет назад была внесена маленькая поправочка. Было:
                            Лицо, правомерно владеющее экземпляром программы для ЭВМ… вправе без разрешения автора или иного правообладателя… большой список всякого разного
                            стало:
                            Лицо, правомерно владеющее экземпляром программы для ЭВМ… вправе без разрешения автора или иного правообладателя… большой список всякого разного, если иное не предусмотрено договором с правообладателем

                            И эта маленькая добавка в конце оччено существенно изменила-таки смысл закона, согласитесь? Вы лицензионное соглашение на Windows читали? Ну так просветитесь…
                            • –1
                              А лицензионное соглашение является договором в юридическом смысле?
                              • +1
                                Является, естественно. Но там та самая «маленькая добавка в конце» в соответствующей статье в Гражданском кодексе на самом деле очень размытая: «Применение положений, предусмотренных настоящей статьей, не должно противоречить обычному использованию программы для ЭВМ или базы данных и не должно ущемлять необоснованным образом законные интересы автора или иного правообладателя.»
                                Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».
                                • 0
                                  Т.е. не «как сказал правообладатель в лицензионном соглашении», а «сами между собой разберётесь, на крайняк, в суде».
                                  Это в части декомпиляции, создания резервных копий и прочего.

                                  «Внесение в программу для ЭВМ или базу данных изменений» и «исправление явных ошибок» — это пункт 1280 подраздел 1 параграф 1. В нём — никакой размытости: «если иное не предусмотрено договором с правообладателем» и точка.
                              • +2
                                Спасибо за информацию, я не знал об этой поправке.
                                Ещё бы без уничижительно-поучительного тона, было бы совсем хорошо.
                        • +8
                          Так никто (из практиков) не отрицает что в опенсорце тоже хватает говнокода.
                          Однако если ты сталкиваешься с тем что у тебя чего не то не работает в опенсорце то открыв исходник можно как минимум понять почему, и вероятно, как минимум, найти обходной путь в виде условий при которых оно будет работать.
                          А как максимум можно и пропатчить, а то и вообще переписать нормально.

                          В случае же закрытыми исходниками можно только догадываться о том что там булькает в чёрном ящике.
                          А уж процесс поиска решения и подавно требует больше навыков и времени.
                          Под вендой я обычно пользовался процесс монитором и долго листал его простыни, настраивал фильтры, и иногда удавалось после долгого выжигания глазами листингов и медитаций находить решение: там файл подсунуть, тут права подкрутить, там реестрик подредактировать и тп.
                          Гуру же берутся за дебагер, копаются в асмовых листингах.
                          Но в целом людей которые могут и у которых есть мотивация и возможности (время) — крайне мало.
                          Людей которые могут нагуглить исходник, пролистать текст и чего то понять всё же больше, и времени на это нужно меньше.

                          Касательно линукса для десктопов — там много всего есть, проблема часто в том, что туда пытаются идти с идеологией МС, а потом говорят что линукс говно.
                          Нет там АД, и оно там не надо. Там другой подход.
                          Есть керберос, есть nfs, есть возможность монтировать свою хомдиру на входе авторизовавшись керберосом — те фактически получить некий аналог АД и роуминговых профилей.
                          Если нужны какие то политики с настройками и пр — для этого есть отдельные средства, а примитивные случаи просто скриптуются.

                          Касательно юзабилити и пр, тут зависит от потребностей, ожиданий и кривизны рук.
                          В целом опять же не надо приходить и сравнивать с вендой, тут всё по другому.
                          В венде скачать ехе с помойки и запустить — обычное дело, в линухе ацкая дикость и исключение из правил.
                          В венде ты ищешь дрова по дискам да по сайтам и ставишь, а линухе оно как правило или уже есть или надо искать на загончиках где пилят ядра или дрова, а их совсем не много. Иногда достаточно ручками добавить пару строк и пересобрать.
                          • –9
                            У Linux всё очень плохо с поддержкой железа и разных низкоуровневых фишек. Чуть ли не любая железка под Linux не раскроет все 100% своего функционала, а хоть что-нибудь из функций будет отсутствовать или не заработает как положено.
                            Вот взять хотя бы NTFS, раз уж статья о ней. Как-то обнаружил, что на внешнем USB-диске появились ошибки: имя одного из файлов сменилось на кашу из символов, и удалить этот файл не выходит — пишет, что файл повреждён.
                            В винде я бы сделал chkdsk и всё, а в Linux вдруг с удивлением обнаружил, что там полностью отсутствует мало-мальски функциональный инструмент для исправления NTFS-ошибок. Всё, что может мне предложить Linux — это утилиты из комплекта NTFS-3G, которые ntfsfix и ntfsck. И обе они исправляют лишь небольшое подмножество ошибок — фактически, только чтобы файловая система после фикса вообще могла смонтироваться. Полез гуглить — везде советуют загрузиться из-под винды и пофиксить.
                            Ну весело… Получается, что в Linux нет полной поддержки одной из самых распространённых домашних файловых систем? Все эти экзотические Linux'овые ФС ни одно виндовое устройство не видит, да и всякие смарт-телевизоры тоже что-то не очень. У FAT32 ограничение на размер файла. И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?
                            • +12

                              Если я правильно помню, тут проблема не совсем в линуксе, NTFS абсолютно закрытая ФС без какой-либо официальной документации, и то, что она доступна в линуксе хоть как-то, уже очень большое достижение (если я не прав, буду рад узнать об этом)


                              И на чём же к примеру хранить фильмы

                              exFAT? Правда, я не интересовался, чё там с исправлением ошибок)

                              • 0
                                С exFAT довольно странная вещь. Я, правда, пару раз обжёгшись больше с ней не разбирался, возможно, не умею её готовить. А случилось вот что: отформатировал флешку дома (Win7 x64), принёс на работу – винда (Win7 x64) её не понимает. Ладно, переформатировал на работе, всё стало хорошо, принёс домой – моя винда её не понимает.

                                Отформатированную дома флешку, кстати, прекрасно понимала домашняя же XP SP2 с апдейтом для поддержки exFAT.
                                • +1
                                  exFAT отвратительная файловая система с точки зрения надежности.
                                  1. в отличие от FAT16,32 таблица заполняется, только для фрагментированных файлов.
                                  2. таблица FAТ в одном экземпляре. Кроме этого в некоторых ОС при форматировании (создании таблицы) не удосуживаются очищать область, которую будет занимать таблица. Основной структурой контроля занятого пространства считают Bitmap. В итоге анализируя разрушения.

                                  В общем при незначительных разрушения директории можем получить существенные потери при попытке воспользоваться средствами исправления ошибок (потери большие нежели в случае FAT32).

                                  ExFAT использовать, только для хранения данных потеря которых не будет критична.
                                • +7
                                  И на чём же к примеру хранить фильмы, чтобы иметь возможность пофиксить ошибки ФС в случае их появления?

                                  Ext4, XFS, Btrfs. Не вижу в них экзотики.


                                  в Linux нет полной поддержки одной из самых распространённых домашних файловых систем

                                  Потому что ФС закрытая, обложенная патентами и авторскими правами. Сама Microsoft помогать даже документацией не желает.

                                  • 0
                                    Ext4, XFS, Btrfs

                                    Чё там с поддержкой их приставками, телевизорами, виндами?

                                    • +9
                                      Чё там с поддержкой их приставками, телевизорами
                                      Трясите производителей, однако. Все эти приставки и телевизоры используют Linux и «внутри себя» используют ext3/ext4 и xfs, однако на внешних HDD их не поддерживают — и кто в этом виноват? Linux?

                                      виндами?
                                      Если винда у вас есть, то и виндовый chkdsk у вас есть, не вижу проблемы.
                                      • –13
                                        и кто в этом виноват? Linux?

                                        В контексте данной ветки неважно, кто виноват, важно, что линукс и используемые им технологии, как ни крути, не готовы для повседневного использования)


                                        виндовый chkdsk у вас есть

                                        Он умеет проверять и исправлять «Ext4, XFS, Btrfs»?

                                        • –6

                                          А за что заминусовали-то, да ещё и в карму? Я какую-то неправду сказал?

                                          • –1
                                            Вы что-то не так сказали в сторону Linux-а. Уже не раз замечаю такое явление. Стоит кому-то что-то сказать на эту ОС, как тут же откуда-то прилетают минуса.
                                          • +6
                                            В контексте данной ветки неважно, кто виноват
                                            Извините, но если вам неважно — кто виноват в проблеме, то как вы собираетесь её исправлять? Началось-то всё с того, что в Linux, оказывается отвратительные и никуда не годные технологии.

                                            важно, что линукс и используемые им технологии, как ни крути, не готовы для повседневного использования)
                                            Потому что производители «приставок и телевизоров» целенаправленно и сознательно делают невозможным их использование.

                                            Вы уж меня извините, но… это не техническая проблема и технического решения она не имеет!

                                            Он умеет проверять и исправлять «Ext4, XFS, Btrfs»?
                                            Нет, но в этом случае вас не будет напрягать тот факт, что поддержка NTFS в Linux, по понятным причинам, ограниченная.
                                            • 0
                                              но если вам неважно — кто виноват в проблеме

                                              Передёргивать не надо, я же указал — в контексте данной ветки.


                                              Потому что производители «приставок и телевизоров» целенаправленно и сознательно делают невозможным их использование.

                                              Ни капельки не споря с этим, вынужден ещё раз заметить, что из-за этого линуксовые технологии непригодны для конечных пользователей, и форматирование флешек для них «Ext4, XFS, Btrfs» по-прежнему неприемлемо, потому что эту флешку никто не сможет прочитать.


                                              вас не будет напрягать

                                              Меня ничего не напрягает, я прекрасно понимаю, как и почему сложилась такая ситуация, какая есть, да и все мои девайсы поддерживают Ext4) Но, что бы вы мне ни отвечали, простым пользователям (не мне), которые хотят закинуть фильм на флешку и посмотреть на приставке или перекинуть соседу, на это всё глубоко плевать: им надо чтобы просто работало. А оно не работает. Такие дела.

                                              • +2
                                                для конечных пользователей, и форматирование флешек для них «Ext4, XFS, Btrfs» по-прежнему неприемлемо, потому что эту флешку никто не сможет прочитать.

                                                Гм, у меня на флэшке два раздела, один в VFAT, второй в ext3. Не вижу никаких проблем с ext3, все линуксы её читают.

                                                Тот же андроид 6, в чем SD-карту форматирует в режиме расширения основной памяти? Ну 100% там не FAT.

                                                простым пользователям (не мне), которые хотят закинуть фильм на флешку и посмотреть на приставке или перекинуть соседу, на это всё глубоко плевать: им надо чтобы просто работало. А оно не работает.

                                                А пока у соседа винды нет — все работает. А вот если у соседа винда — вот тогда катастрофа.
                                                • +2

                                                  Как только винда где-то появляется, так всё, приехали. Эту фс не умею, на этой флешке 2 раздела… Винда говно.

                                                  • 0
                                                    С двумя разделами на флэшке у меня никаких проблем. На первом — vFAT, читается на любой винде. На втором ext3 — у меня читается. Но у меня для этого дела драйвер поставлен на винду поставлен. Писать он тоже может, это я уже я сам остерегаюсь.
                                                    • 0
                                                      Начиная с Windows 10 1703 несколько разделов на флешках наконец работают.
                                                    • 0
                                                      А вот если у соседа винда

                                                      Ну вообще-то именно с этого и началась данная ветка.


                                                      Тот же андроид 6

                                                      Чего вы андроид-то приплели, у андроида всё хорошо, я про него ничего не писал и не собираюсь.


                                                      все линуксы её читают

                                                      А приставки, телевизоры (которые не на андроиде) и соседские винды? Не надо прикидываться, будто проблемы не существует.

                                                      • –2
                                                        Понимаете чем беда…

                                                        Когда я 34 года назад начинал работать программистом, пакет дисковод мог ставится только на тот дисковод, где он писался. А на соседний — не стоило, ибо юстировка иная.

                                                        Потом это побороли, сделали совместимость между разными устройствами одной машины.

                                                        Потом — между разными устройствами однотипных машин.

                                                        Теперь мы имеем физическую совместимость между устройствами совсем разных машин. Осталась — логическая совместимость.

                                                        В стандартах на USB-флэш и SD-карты прописан FAT. И до сих пор не каждая флэшка будет беспроблемно работать в ext3.

                                                        Во флэшке есть внутренний контроллер, который обеспечивает трансляцию логический секторов в физические, равномерное количество записей на сектора и замену сбойных секторов. Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.

                                                        Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.

                                                        А софт… Ну моя windows XP читает ext3. Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.
                                                        • 0
                                                          > Хотите — научите вашу. И соседа. В конце концов «из коробки» в винде нет ни экселя ни поверпоинта.

                                                          Не с целью флуда, однако:
                                                          У вас есть драйвер монтирующий флешку или жд в экст4 фс в «мой компьютер», при этом не висящий постоянно в отдельном сервисе?
                                                          • +2
                                                            Нету, висит сервис «Ext2 management module». А чем он мешает?
                                                            • 0
                                                              У меня ранее его прибивали антивирусы и всякие «оптимизаторы», приходилось добавлять в исключения, а это уже жирный минус был в использовании.
                                                              • +3

                                                                Это жирный минус "оптимизаторам" и "антивирусам".

                                                                • +6
                                                                  То есть то, что какие-то «левые» программы без спроса нарушают работоспособность нормальных программ — это минус не левых программ, а тех, чью функциональность нарушали?
                                                                  Отличная логика…
                                                                  • 0
                                                                    Хороший пример. В ядре я такого особенно наелся. Особенно мне нравилось когда разработчик вызывал IoCallDriver, если драйвер который он вызвал, породил исключение, из-за неверной передачи параметров, то решение их было очень простым, обернули в try/except. Вместо того чтобы разобраться в причине. И таких разработок больше чем множество. Кстати спорить с такими разработчиками не возможно. Люди не в состоянии воспринять твою мысль в принципе.
                                                                    • 0
                                                                      Простите, но блокировка антивирусом абсолютно любого стороннего драйвера — это не нормальное функционирование нормальной программы. И следует помнить, что антивирус для программ, а не программы для антивируса. Секете?
                                                                      • 0
                                                                        Если честно нифига не «секу» то, что вы написали, как и то, кому вы это написали.
                                                              • +1
                                                                Это контроллер оптимизирован для FAT и иногда просто зависает для других файловых систем.

                                                                при анализе алгоритмов NAND контроллеров можно сказать, что в основной массе их микропрограммы они не оптимизируются для какой-либо файловой системы. Зависание — это уже признак проблемы устройства.
                                                                Я понимаю ваше желание выйти за рамки стандарта. Потерпите немного. современные SDHC-карты уже готовы к ext3, USB — ну или выбирать модель или ждать лет 5.

                                                                Простите, а что именно в них готово, что не приготовлено в USB flash? В SD(SDHC) картах логика работы контроллеров аналогична логике работы контроллеров USB_NAND. Можно рассмотреть примеры различных контроллеров и их нюансы трансляции.
                                                                • 0
                                                                  Ну значит такое качество у вас анализа было… :-) Для оптимизации под FAT хватает того, что контролер считает, что часто перезаписываемая область находится в начале диска, а не в его середине или в конце

                                                                  Эксперимент очень простой. Берете 5-10 неиспользованных флэшек разных моделей. Разбиваете на 2 раздела. Один — большой под FAT, второй в конце, 1-2 гига, под ext3. При попытке растарить на него почти гигабайтный архив — запись зависает примерно в половине случаев.

                                                                  Потом берете ещё 5-10 флэшек — и пытаетесь их замучать при помощи одного раздела FAT. И все работает отлично.

                                                                  Можете сами проверить. Но мы покупаем флэшек в два раз больше, чем нам надо. И не всегда хватает. Последний раз брали sundisk на 8 и 16 гигов — они чуть получше, но тоже виснут.

                                                                  Можете ещё DD сделать с посекторным копированием. Тут уже процентов 75, что флэшка помрет.
                                                                  • 0

                                                                    А это не может быть простое завышение объема, как любят делать некоторые?

                                                                    • +1
                                                                      Можете ещё DD сделать с посекторным копированием. Тут уже процентов 75, что флэшка помрет.
                                                                      Интересно, я тоже это наблюдал на SD-картах и USB-flash. При попытке «почистить» устройство записями нулей в \Device\PhysicalDriveX у меня карточки умирали насовсем. И я решил, что контроллер не может обрабатывать запись в сектора, близкие к началу, и больше так делать не надо.
                                                                      А это не может быть простое завышение объема, как любят делать некоторые?
                                                                      До умирания устройства были почти полностью забиты данными и никаких проблем с данными не было.
                                                                      • 0
                                                                        Интересно, я тоже это наблюдал на SD-картах и USB-flash. При попытке «почистить» устройство записями нулей в \Device\PhysicalDriveX у меня карточки умирали насовсем. И я решил, что контроллер не может обрабатывать запись в сектора, близкие к началу, и больше так делать не надо.
                                                                        это были USB flash с изношенной NAND памятью, достаточно износа в области хранения служебных структур, чтобы получить мертвое изделие при первом же сбое в механизме трансляции.
                                                                        • –1
                                                                          Интересно, что у меня «изношенными» оказывались только что купленые устройства, что SD 1.1, что USB 2.0.

                                                                          Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)

                                                                          Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы FAT?
                                                                          • +1
                                                                            Или все-таки речь о том, что посекторное обновление хорошо поддерживается лишь для ограниченной области таблицы FAT?

                                                                            Вас не смутило, что любой физический блок может выполнять любую логическую роль? Ничего, что за время жизни USB Flash местоположение FAT таблиц многократно сменится согласно физического адреса, хотя согласно LBA адресации положение будет неизменным?

                                                                            Интересно, что у меня «изношенными» оказывались только что купленые устройства, что SD 1.1, что USB 2.0.

                                                                            Претензии по качеству конечного изделия предъявляйте производителю.

                                                                            Вы имеете ввиду, что они «изнашиваются» за время транспортировки с завода? :-)

                                                                            глядя на качество NAND памяти (изначально допустимое количество битовых ошибок и сильно возросшие размеры ЕСС) могу сказать, что я имею в виду некачественные изделия, которые выходят из строя куда раньше, чем обещал производитель.

                                                                            • –1
                                                                              Меня не смущает, что небо голубое, а трава зеленая. А вас это разве смущает?

                                                                              Ничего, что за время жизни USB Flash местоположение FAT таблиц многократно сменится согласно физического адреса, хотя согласно LBA адресации положение будет неизменным?

                                                                              Вот и я про о том же. Этот механизм намного лучше работает для начала диска, чем для других областей.

                                                                              Можно строить много гипотез, почему так происходит. Например, по одной из них, в начале диска каждый сектор транслируется в отдельный физический блок. Понятно, что такой блок будет использоваться неэффективно, зато увеличивается надежность.

                                                                              я имею в виду некачественные изделия

                                                                              Ну тогда назовите те, которые вы считаете «качественными». Проверим, наблюдается ли этот эффект на них.
                                                                              • +1
                                                                                Вот и я про о том же. Этот механизм намного лучше работает для начала диска, чем для других областей.

                                                                                этому механизму совершенно безразлично, где работать. Все блоки равноправны.
                                                                                Можно строить много гипотез, почему так происходит. Например, по одной из них, в начале диска каждый сектор транслируется в отдельный физический блок. Понятно, что такой блок будет использоваться неэффективно, зато увеличивается надежность.

                                                                                можно попросить Вас ознакомиться с хотя бы общими принципами работы NAND контроллеров, а то я затрудняюсь комментировать подобные опусы.
                                                                                Ну тогда назовите те, которые вы считаете «качественными». Проверим, наблюдается ли этот эффект на них.

                                                                                Они уже вымирающий вид. Те самые старые USB Flash малой емкости с SLC или хотя бы MLC памятью. Рынку нужны дешевые и емкие изделия, а это TLC, которое с рождения неспособно хранить пользовательские данные без ошибок (живет исключительно за счет емких ЕСС)

                                                                                • –1
                                                                                  этому механизму совершенно безразлично, где работать. Все блоки равноправны.

                                                                                  Ну так докажите это. Экспериментами с современными флэшками или ссылками на даташиты изготовителей. Информации об дизассемблировании одной прошивки десятилетней давности — это не доказательство.

                                                                                  я затрудняюсь комментировать подобные опусы

                                                                                  Тогда я вас ещё сильнее затрудню. S25FL256S — 32 блока по 4 килобайта и 5120 блоков по 64. Это вот был один из кандидатов для нашей платы.
                                                                                  • 0
                                                                                    Ну так докажите это.

                                                                                    посмотрите алгоритмы сбора логических образов из дампов полученных из различных USB flash. На том же форуме софтцентра, который доступен публично. Как бы тысячи разных версий NAND контроллеров с некоторыми нюансами работают, но основная суть блочной работы и свободным расположением блоков в рамках логического банка сохраняется.
                                                                                    Экспериментами с современными флэшками или ссылками на даташиты изготовителей.
                                                                                    а ничего, что эта информация на данный момент имеет коммерческую ценность?

                                                                                    Тогда я вас ещё сильнее затрудню. S25FL256S — 32 блока по 4 килобайта и 5120 блоков по 64. Это вот был один из кандидатов для нашей платы.

                                                                                    а причем это изделие к NAND памяти? И чем оно должно затруднить?
                                                                                    • –1
                                                                                      Ну то есть доказательств у вас нет. У вас есть только ВЕРА в то, что производители не использовали маркетинговые преимущества от увеличения надежности записи в начальные блоки логических адресов.

                                                                                      С другой стороны, у меня — результаты экспериментов. Весьма нестрогие, но показательные.

                                                                                      А любые результаты экспериментов — намного лучше ВЕРЫ.

                                                                                      Мне не важно, что и как там организовано в контроллере. Используются ли блоки разного размера или разные критерии выбора блока для записи или ещё что-то. Но я вижу, что подобный механизм во флэшках есть.

                                                                                      Хотите убедиться — сделайте эксперименты сами.
                                                                                      • 0
                                                                                        Ну то есть доказательств у вас нет. У вас есть только ВЕРА в то, что производители не использовали маркетинговые преимущества от увеличения надежности записи в начальные блоки логических адресов.

                                                                                        пока есть только ваше нежелание просмотреть уже указанные источники, чтобы понять основы алгоритмов контроллеров. Речь идет не о вере, а о постоянном анализе различных алгоритмов NAND контроллеров по мере появления их в готовых изделиях.
                                                                                        С другой стороны, у меня — результаты экспериментов. Весьма нестрогие, но показательные.

                                                                                        Один американец тоже проводил эксперименты со спиртовым уровнем доказывая, что земля плоская (думаю найдете в новостях). Пока результаты ваших экспериментов примерно также достоверны, как результаты доказательств того, что земля плоская.
                                                                                        Мне не важно, что и как там организовано в контроллере. Используются ли блоки разного размера или разные критерии выбора блока для записи или ещё что-то.

                                                                                        т. е. вы хотите сказать, что домыслы куда лучше анализа алгоритмов работы устройств?
                                                                                        Но я вижу, что подобный механизм во флэшках есть.

                                                                                        есть только в ваших выводах, которые основаны без учета алгоритма работы самого NAND контроллера.
                                                                                        Хотите убедиться — сделайте эксперименты сами.

                                                                                        Так делаю, но более детальные и с учетом алгоритмов NAND контроллеров.

                                                                                        • –1
                                                                                          Ну так давайте ссылку на результаты ваших экспериментов. Какая была методика, что делали. Гляну, могли ли они вообще выявить отличия в алгоритмах.

                                                                                          На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами. Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.

                                                                                          Вот подумайте над ответом на этот вопрос.
                                                                                          • 0
                                                                                            Ну так давайте ссылку на результаты ваших экспериментов. Какая была методика, что делали. Гляну, могли ли они вообще выявить отличия в алгоритмах.
                                                                                            Прочтите сначала то, что здесь написано. Приводя примеры с flash памятью научитесь видеть отличия в NOR и NAND, так сказать подготовьтесь к усваиванию материала, а позже выложу на хабр немного материалов по реверс-инжинирингу NAND контроллеров используемых в USB flash.
                                                                                            На самом деле все просто. Есть способ легко, за 5-10 строчек кода, получить маркетинговое преимущество над конкурентами.

                                                                                            какое преимущество?
                                                                                            Вы утверждаете. что эта идея никому кроме меня в голову не пришла? Или все не стали её реализовывать, потому что эти 10 строчек затормозят алгоритм? Или по какой причине? Мифический нейтралитет к файловой системе? Так 99.9% -под FAT.

                                                                                            исходя из алгоритмов работы NAND контроллеров на сегодня наиболее удобна файловая система FAT из-за минимальных паразитных нагрузок. Второе удобство совместимость с различными ОС.

                                                                                            Вот подумайте над ответом на этот вопрос.

                                                                                            этот вопрос возникал бы, если бы не фактический анализ структур трансляторов NAND контроллеров, который показывает, что оптимизации идут несколько в другом направлении (снижение паразитных нагрузок при записи малых объемов данных)
                                                                                            • –1
                                                                                              Преимущество понятно какое. На всех устройствах хранения прежде всего выходят из строя логические блоки, в которые запись идет чаще всего. Когда мы транслируем логический блок в физический — эта закономерность сохраняется. Чем больше записей в один блок — тем больше шансов, что трансляция в конечном итоге приведет нас в сбойный блок.

                                                                                              Самые часто записываемые блоки на FAT — это область таблицы FAT.

                                                                                              С другой стороны, ошибка записи в тело файла — может быть и не обнаружена потребителем. Или выглядеть как артефакты на одном из кадров видео, что потребитель сочтет сбоем видеозаписи, а не флэшки.

                                                                                              Отсюда и желание на тех устройствах, где FAT составляет 99.9% потребления — оптимизировать характеристики под него.

                                                                                              Такая оптимизация может основываться не только на предоставлении преимуществ начальных логическим блокам, но и на преимуществам часто записываемым блокам вообще. При этом планируемое максимальное количество часто записываемых блоков считается исходя из характеристик FAT.

                                                                                              Так что при анализе вы легко можете не понять, что какая-то оптимизация будет хорошо работать на FAT и плохо на ext3. Тут нужен не просто анализ — а моделирование полученного алгоритма.

                                                                                              • 0
                                                                                                Преимущество понятно какое. На всех устройствах хранения прежде всего выходят из строя логические блоки, в которые запись идет чаще всего. Когда мы транслируем логический блок в физический — эта закономерность сохраняется. Чем больше записей в один блок — тем больше шансов, что трансляция в конечном итоге приведет нас в сбойный блок.
                                                                                                Вы пока не понимаете основного механизма ротации блоков. Не получится так, что какой-то один блок сильно износится. Изнашиваться будет равномерно группа блоков, так как роли физических блоков будут изменчивыми. Допустим первые три цикла записи FAT таблиц были в нулевой блок, после глядя на показатель счетчика записей при следующей записи этот блок перейдет в первый невключенный в трансляцию в рамках логического банка но с меньшим значением счетчика записей, а нулевой будет исключен из трансляции. Таким образом изменяемые данные будут постоянно менять свое физическое положение, хотя логически они будут оставаться на прежнем месте. И механизм этот в основе работы практически всех NAND контроллеров (с теми или иными нюансами).
                                                                                                Самые часто записываемые блоки на FAT — это область таблицы FAT.

                                                                                                это никто не оспаривает, но в итоге это не отражается на непосредственно износе каких-то конкретных блоков. Происходит равномерный износ группы блоков и чем меньше статичной информации лежащей на накопителе без изменений, тем эффективнее работает алгоритм выравнивания износа.
                                                                                                Отсюда и желание на тех устройствах, где FAT составляет 99.9% потребления — оптимизировать характеристики под него.

                                                                                                производители занимаются оптимизацией алгоритмов мелких записей, чтобы снижать паразитные нагрузки. И алгоритмам все равно FAT будет или NTFS или Ext. Они просто отработают в силу своих возможностей. Естественно самая меньшая паразитная нагрузка будет в случае FAT из-за организации самой файловой системы.

                                                                                                Такая оптимизация может основываться не только на предоставлении преимуществ начальных логическим блокам, но и на преимуществам часто записываемым блокам вообще. При этом планируемое максимальное количество часто записываемых блоков считается исходя из характеристик FAT.

                                                                                                Так что при анализе вы легко можете не понять, что какая-то оптимизация будет хорошо работать на FAT и плохо на ext3. Тут нужен не просто анализ — а моделирование полученного алгоритма.

                                                                                                Вы не уразумев основной логики работы NAND контроллеров, сейчас описываете очень далекие от эффективных по отношению к NAND памяти приемы.
                                                                                                • 0
                                                                                                  А эта волшебная ротация, на основе чего вообще происходит? Как, после первой записи во все блоки, контроллер отличает занятые блоки от свободных? Через USB ведь TRIM не работает.
                                                                                                  • 0
                                                                                                    А эта волшебная ротация, на основе чего вообще происходит? Как, после первой записи во все блоки, контроллер отличает занятые блоки от свободных? Через USB ведь TRIM не работает.

                                                                                                    микрокод USB-NAND контроллера имеет в распоряжении транслятор, где описываются задействованные блоки в рамках каждого логического банка. При каждой (или после нескольких) перезаписи блока, он исключается из трансляции и переводится в резервные, а его роль начинает выполнять вошедший в трансляцию.

                                                                                                    сегодня или в понедельник выложу на хабр описание алгоритма работы одного из USB NAND контроллеров (немного скриншотов приготовлю для лучшей усвояемости материала). В ЕСС, глубины транслятора погружаться не буду, чтобы не пугать читателей. Полагаю, тогда многие вопросы отпадут.
                                                                                                  • –1
                                                                                                    Происходит равномерный износ группы блоков и чем меньше статичной информации лежащей на накопителе без изменений, тем эффективнее работает алгоритм выравнивания износа.

                                                                                                    Гм, пишем на флэшку до полного заполнения, потом удаляем все файлы или форматируем флэшку. Что будет? «Статической информации» — ноль. Будет ли при этом алгоритм выравнивания износа работать эффективно?

                                                                                                    Если будет — это означает, что флэшка понимает удаление файлов, то есть заточена под файловую систему. А затачивать её имеет смысл только под FAT. Если не будет — значит вы недопонимаете тонкости или некорректно формулируете определения.

                                                                                                    FAT обладает следующими особенностями:

                                                                                                    • Наиболее часто перезаписываемая область (таблица FAT) находится в начале диска
                                                                                                    • Заполнение диска идет с начальных секторов. Более того, Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.
                                                                                                    • Создание файла обычно идет в 4 приема: таблица FAT, каталог, сам файл, перезапись длины в каталоге.
                                                                                                    • Области каталогов и данных файла обычно находятся в разных физических блоках флэш, то есть удалены по логическим адресам.


                                                                                                    Все это не так для ext2.

                                                                                                    • Часто перезаписываемые области (bitmap и inode) в середине диска
                                                                                                    • Заполнение идет равномерно по всему диску. То есть с точки зрения самой флэшки диск быстро становится заполнен на 100%.
                                                                                                    • Создание файла идет в 4 приема bitmap, inode, каталог, тело файла.
                                                                                                    • При этом во многих случаях bitmap и inode попадают в один физический блок флэшки. а каталог и тело файла — в другой физический блок. Таким образом, кэширование на 1 блок — очень выгодно для ext2.


                                                                                                    Учетом любой из этих особенностей можно сделать оптимизацию под ту или иную файловую систему.

                                                                                                    Например, можно считать все логические блоки, в которых никогда не было записи — свободными. И включить в ротацию соответствующие физические блоки. И это будет огромное преимущество именно для FAT.

                                                                                                    А можно вообще сделать границу между свободными и несвободными блоками по записанному логическому блоку с наибольшим адресом. И это будет ещё большее преимущество именно для FAT.

                                                                                                    Грубо говоря, если файлы занимают 10% диска — на FAT можно легко включить в ротацию 90% диска. А вот на ext2 даже 5% занятого места ограничивают ротацию считанными резервными блоками.

                                                                                                    И это помимо тех оптимизаций, о которых я писал ранее.
                                                                                                    • 0
                                                                                                      Гм, пишем на флэшку до полного заполнения, потом удаляем все файлы или форматируем флэшку. Что будет? «Статической информации» — ноль. Будет ли при этом алгоритм выравнивания износа работать эффективно?

                                                                                                      для подавляющего большинства USB flash это будет означать, что придется переписать лишь группу блоков с метаданными файловой системы. По мере записи новой информации. Но по мере записи в пустые блоки, которые согласно транслятора заняты, ротация будет происходить. Пусть не самый эффективный алгоритм, но достаточно неплохо отработает в случае удаления, форматирования, при записи новых данных.
                                                                                                      Если будет — это означает, что флэшка понимает удаление файлов, то есть заточена под файловую систему. А затачивать её имеет смысл только под FAT. Если не будет — значит вы недопонимаете тонкости или некорректно формулируете определения.

                                                                                                      USB Flash не понимает нюансов файловой системы за исключением некоторых очень древних «проб пера» авторов фирмварей, которые давно показали неэффективность.
                                                                                                      FAT обладает следующими особенностями:

                                                                                                      Наиболее часто перезаписываемая область (таблица FAT) находится в начале диска
                                                                                                      Заполнение диска идет с начальных секторов. Более того, Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.

                                                                                                      справедливо для логического пространства. В физическом все будет выглядеть по другому. Опять же пример в статье, что произойдет при перезаписи блока.
                                                                                                      Грубо говоря, если файлы занимают 10% диска — на FAT можно легко включить в ротацию 90% диска. А вот на ext2 даже 5% занятого места ограничивают ротацию считанными резервными блоками.

                                                                                                      тут вы лишь декларируете, что не понимаете сути алгоритма NAND контроллера. Ротация будет осуществляться в рамках логического банка (количество банков — это уже нюанс работы того или иного NAND контроллера). И неважно речь пойдет о метаданных EXT или FAT. Разница в том, что паразитных нагрузок в случае EXT будет больше, чем в случае FAT, так как для перезаписи крошечных объемов придется переписывать целиком крупные блоки.
                                                                                                      И это помимо тех оптимизаций, о которых я писал ранее.

                                                                                                      пока что описание ваших оптимизаций, лишь плод вашего воображения, а не фактические реализации в микропрограммах.

                                                                                                      • –2
                                                                                                        Разница в том, что паразитных нагрузок в случае EXT будет больше, чем в случае FAT

                                                                                                        Почему? Потому что ext2 кэшируется и несколько обновлений одного сектора сливаются в одно? Потому что 4 записи для создания короткого файла на FAT вам кажутся сильно меньше 4 записей для той же операции на ext2? Или потому, что флэшка оптимизирована для FAT?

                                                                                                        Вот и подумайте, почему 4 для ext2 вам кажутся сильно больше, чем те же 4 для FAT.
                                                                                                      • 0
                                                                                                        > Если мы удалим файл и на его место запишем другой — будет задействовано прежде всего освободившееся место в начале диска.

                                                                                                        Интересно, это во всех реализациях FAT так?
                                                                                                        Логично было для разработчиков драйверов ФС в зависимости от конкретных требований добавить в этот алгоритм одну из двух или сразу две оптимизации (первую по крайней мере во времена царствования старых жестких дисков). Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.
                                                                                                        Во-вторых, выделять место в ранее не использованном пространстве, чтобы повысить вероятность восстановления данных после удаления (необходимые данные о ранее занятых, а после освобожденных кластерах можно хранить «внутри» драйвера ФС).

                                                                                                        > Области каталогов и данных файла обычно находятся в разных физических блоках флэш, то есть удалены по логическим адресам.

                                                                                                        > Все это не так для ext2.

                                                                                                        > а каталог и тело файла — в другой физический блок.

                                                                                                        Почему для FAT и ext2 в этом случае будет разница?
                                                                                                        Могу ошибаться, но в обоих случаях каталог — это тоже файл (за исключением корневого каталога FAT). И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…
                                                                                                        • 0
                                                                                                          Во-первых, выделять по возможности нефрагментированный участок (последовательно расположенные кластеры) для ускорения последовательного чтения файла.

                                                                                                          Для этого на этапе создания файла ОС должна хотя бы примерно понимать его размер. А обычная схема создания файла этого не предусматривает. open/write/close, и только на этапе close, по положению файлового указателя определяется размер файла. Да, есть SetFilePointer и SetEndOfFile в WinAPI, в Си (POSIX) можно сделать ftruncate, но… вы используете эти вызовы в своих программах? Вот и другие не используют. Ну разве что в программах копирования или разархивирования файлов.

                                                                                                          Так что самый частый случай — в момент создания файла длина неизвестна, а известна она становится лишь при закрытии файла.

                                                                                                          Так что ваша оптимизация присутствует в ОС, но работает лишь в тех редких случаях, когда длина известна заранее — то есть в основном при копировании или разархивировании файла.

                                                                                                          Во-вторых, выделять место в ранее не использованном пространстве,

                                                                                                          В FAT я такого не видел. Наоборот, стараются предотвратить разрастание занятой области. Одна из причин — на внешних дорожках старых дисков плотность записи меньше, чем на внутренних (число секторов фиксировано, физическая длина внешних дорожек больше). То есть запись надежнее.

                                                                                                          Почему для FAT и ext2 в этом случае будет разница?

                                                                                                          Цитата из вики

                                                                                                          Ядро Linux, используя число индексных дескрипторов, содержащих каталоги, пытается равномерно распределить inode каталогов по группам, а inode файлов старается по возможности переместить в группу с родительским каталогом

                                                                                                          Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру. А операция — «прочли каталог, потом читаем файл» — это частая операция и нуждается в оптимизации. Размещение inode в группе с каталогом практически гарантирует, что данные файла будут в той же группе (ну пока файл не слишком разросся).

                                                                                                          И располагаться они будут в обеих ФС с некоторой (достаточно большой) вероятностью в разных физических блоках флэшки…

                                                                                                          Для 2хмеговый физических блоков флэш и файлов меньше 512 байт — вероятность попасть в один и тот же физический блок достаточно велика.
                                                                                                          • 0
                                                                                                            Грубо говоря, разница будет потому, что ext2 оптимизирует движение головки по винчестеру.

                                                                                                            Как она это делает, если геометрия накопителя — неизвестна?
                                                                                                            • 0
                                                                                                              Без перфекционизма, но делает. Исходя из того, что сектора с близкими номерами — требуют меньше времени на перемещение головок, чем сектора с очень дальними номерами.

                                                                                                              Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей. Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась целью
                                                                                                              • –1
                                                                                                                Во времена разработки еxt2 — 1993 год — обычно совпадала. Но была неизвестна скорость вращения диска. Так что полная оптимизациия — и тогда не ставилась целью
                                                                                                                совпадала для MFM/RLL накопителей. А 1993 год — это 7 лет прошло с момента появления IDE. В которых уже CHS параметры были виртуальными.
                                                                                                                • –1
                                                                                                                  Вы путаете метод записи битов на диск (FM/MFM/RLL) с методом связи диска с компьютером (ST-506/ESDI/SCSI/IDE (он же АТА)).

                                                                                                                  Ну это как-то несерьезно — путать мягкое с кислым. Через IDE работали и MFM диски размерами 20-40 мегабайт.

                                                                                                                  Проблемы встали, когда размеры начали выходить за пределы, допустимые для IDE. Вот тогда LBA (ATA-1) запоздал и появились варианты с подменой геометрии.

                                                                                                                  Но большинство дисков 1993 года — вполне жили в CHS с натуральной геометрией. Насколько мне помнится, тогда самыми популярными были 80мегабайтные диски, а им трансляция ещё не нужна была.

                                                                                                                  • 0
                                                                                                                    Вы путаете метод записи битов на диск (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" исполнении.

                                                                                                                    Говоря о коннере, можно сказать, что для тех времен весьма интересная микропрограмма с развитой терминальной системой.
                                                                                                                    • 0
                                                                                                                      Насколько я помню, 3.5 — это была экзотика для 1993 года. Большинство винчестеров было 5.25.

                                                                                                                      см, мой пост выше, 1053 дорожки — это как раз тот случай, когда физическая геометрия не лезла в CHS.

                                                                                                                      P.S. Вы, похоже, путаете год разработки модели с годом её популярности на рынке.
                                                                                                                      • 0
                                                                                                                        Насколько я помню, 3.5 — это была экзотика для 1993 года. Большинство винчестеров было 5.25.
                                                                                                                        обратите внимание, что при одинаковых технологиях тех времен, на 5,25 диск можно было нанести еще больше треков, ибо реально площадь выше. 3,5" показательно, что даже на более модный 3,5" форм фактор было неуместно говорить о реальной CHS адресации.
                                                                                                                        P.S. Вы, похоже, путаете год разработки модели с годом её популярности на рынке.
                                                                                                                        Похоже, что Вы были уверены, в том, что CHS параметры были настоящими, а производители несколько раньше их сделали виртуальными.
                                                                                                                        • 0
                                                                                                                          Суть в том, что 3.5 — это были дорогие современные винчестеры для ноутбуков, а 5.25 — делались для массового сегмента и по более старым технологиям. Кроме того, 5.25 бывали и высоты 2U. Представляете, сколько блинов там размещалось? А вот 3.5 — это 1/2U или 1/4U. То есть 1-2 блина максимум.
                                                                                                                          • 0
                                                                                                                            Суть в том, что 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 нет.

                                                                                                                            • 0
                                                                                                                              Естественно представляю и как их реальную геометрию, так и некоторые особенности микропрограмм.

                                                                                                                              Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.

                                                                                                                              Вы расскажете на чем основаны Ваши выводы касательно оптимизаций и почему SD карты уже готовы, а USB flash нет.

                                                                                                                              Про оптимизации много раз уже говорил, а выводы основаны на опыте,

                                                                                                                              Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.
                                                                                                                              • 0
                                                                                                                                Более того, вы уже признали наличие одной оптимизации. А этого достаточно для объяснения результатов моих экспериментов.
                                                                                                                                скорее вы притянули за уши трактовку, как некое признание.
                                                                                                                                Про оптимизации много раз уже говорил, а выводы основаны на опыте,
                                                                                                                                то есть вы из-за того, что у вас зависли некоторые USB flash без каких-либо предпосылок сделали выводы, что виной тому оптимизации под FAT? А как же анализ принципов работы устройства, чтобы доказать, что виной тому оптимизации для FAT и что это не просто тыканье пальцем в небо?

                                                                                                                                Также пролейте свет на то, что ж такого в SD картах, что они по вашему мнению готовы к разным файловым системам, а USB flash нет? Для более интересного вашего объяснения уточню, что алгоритмы работы с NAND памятью идентичные и у тех и у других накопителей в зависимости от производителя.

                                                                                                                                Зато из дисков очень тяжело извлечь годы их реальной популярности на рынке.
                                                                                                                                дата выпуска может подсказать.
                                                                                                                      • 0
                                                                                                                        Были и восьмидесятки с ST-506 по двум шлейфам, с MFM. У меня была такая — на 2 слота 5.25.
                                                                                                                  • 0
                                                                                                                    Без перфекционизма, но делает. Исходя из того, что сектора с близкими номерами — требуют меньше времени на перемещение головок, чем сектора с очень дальними номерами.

                                                                                                                    А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.

                                                                                                                    Собственно геометрия (CHS) известна, прописана в MBR, просто сейчас совсем не совпадает с настоящей.

                                                                                                                    Вот именно. Там может быть и 16 блинов с виртуальным преобразованием LBA в CHS, которое совсем не отвечает реальному положению дел. И трюк вида «быстрее переключиться на другую головку в следующем секторе, пока блин вращается, interleave вот это все» уже не будет однозначно работать.
                                                                                                                    • +1
                                                                                                                      А номера-то логические? Какова трансляция из CHS в LBA? Вполне могут быть и не близкими.
                                                                                                                      Это вы уже из пальца какую-то фигню вытаскиваете.

                                                                                                                      Да, могут. Иногда (чтобы скрыть «плохие блоки») какой-нибудь сектор могли и «за можай», на самый край диска. Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?

                                                                                                                      А она реально очень сильно ускоряла работу с дисков до появления SmartDrv.
                                                                                                                      • 0
                                                                                                                        Это вы уже из пальца какую-то фигню вытаскиваете.

                                                                                                                        Что CHS — не всегда реальны? Нет, это факт. Что соседние блоки могут не быть соседними физически? Тоже факт. В среднем — да, должны быть рядом.

                                                                                                                        Но в среднем — так не было, иначе какой был бы смысл в дефрагментации?

                                                                                                                        Все верно, так же как read ahead.

                                                                                                                        Но при всем при этом есть определенный алгоритм трансляции логического номера блока в CHS, (на уровне, например, BIOS или DOS, если уж вспоминать старину). И это будет трансляция в виртуальный CHS.
                                                                                                                        • 0
                                                                                                                          на уровне, например, BIOS или DOS, если уж вспоминать старину
                                                                                                                          BIOS и DOS никогда ничего не транслировали. После появления IDE этим стал винчестер заниматься — но он, разумеется учитывал то, что BIOS и DOS считали что CHS — это таки «настоящие» CHS…
                                                                                                                          • 0
                                                                                                                            BIOS и DOS никогда ничего не транслировали

                                                                                                                            Fat оперирует линейными номерами блоков же? Значит, транслирует.
                                                                                                                      • +1
                                                                                                                        Номера логические. Но понятно, что сектора 1700 и 1800 ближе к друг другу, чем сектора 700 и 95000. Так что без перфекционизма — но оптимизируется.
                                                                                                                        • +1
                                                                                                                          Номера логические. Но понятно, что сектора 1700 и 1800 ближе к друг другу, чем сектора 700 и 95000. Так что без перфекционизма — но оптимизируется.

                                                                                                                          неудачный пример. С учетом зонного распределения с вашими цифрами может быть меньшим маршрут от 700 до 95000, нежели от 1700 до 1800.

                                                                                                                          Лучше показать пример: очередь на чтение из трех секторов 100, 800 000 000, 100 000 000 будет исполнена, как 100, 100 000 000, 800 000 000. В таком примере достаточно очевидно преимущество в операциях позиционирования. В случае мелких смещений смысл в сортировке есть, так как эффективно отработает упреждающее чтение (look ahead)
                                                                                                                          • 0
                                                                                                                            В среднем более мелкий маршрут — быстрее более крупного. Это именно в среднем и не касается очень малых маршрутов (в пределах цилиндра) и очень больших. Но в среднем — именно так.
                                                                                                      • 0
                                                                                                        пример анализа одного из алгоритмов USB NAND контроллеров с картинками. По факту их проводилось великое множество (уж больно много разных NAND контроллеров). Естественно хватает отличий и ухищрений. Но нет ничего близко похожего на ваши утверждения.
                                                                                                        • –3
                                                                                                          Ну если это называть анализом… Проанализирован только нижний слой алгоритма. Верхний вы даже не пытались анализировать. Чуть позже прямо там напишу вопросы, на которые вы не ответили.
                                                                                                          • 0
                                                                                                            Ну если это называть анализом… Проанализирован только нижний слой алгоритма. Верхний вы даже не пытались анализировать. Чуть позже прямо там напишу вопросы, на которые вы не ответили.


                                                                                                            А вы не сочиняйте алгоритмов, которых нет. Сначала найдите признаки их существования, где-то кроме как у Вас в фантазиях. Причины того, что USB flash у вас умирали с использованием Ext совсем в другом. Разберите хотя бы структуры хоть одной из фирмварей USB_NAND контроллера, проанализируйте хоть один код, чтобы понять задачи MCU, что в подавляющем случае они не занимаются анализом данных. У них и так хватает нагрузки.
                                                                                                            • 0
                                                                                                              Здесь верно лишь то, что для оптимизации под FAT не нужен анализ данных. Вполне хватает анализа адреса записываемого сектора.
                                                                                                              • 0
                                                                                                                Здесь верно лишь то, что для оптимизации под 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 контроллера? Разбор огромного количества разных контроллеров показывает, что нет. Оптимизации разработчиков идут несколько в другом направлении, что сказывается на уменьшении паразитных нагрузок для записи мелких блоков. Подобные оптимизации снижают нагрузку как при записи метаданных файловой системы, так и при записи небольших файлов.
                                                                                                                • 0
                                                                                                                  А ничего. В начале у нас кроме FAT ещё и корневой каталог. И просто каталоги. В итоге, если мы при ротации для блоков ниже 32 MiB будем выбирать наименее изношенный физический блок, а для остальных — более изношенный физический блок, то изношенные физические блоки у нас осядут в неизменяемых данных.

                                                                                                                  Ещё полезная оптимизация — физические блоки, в которых вообще никогда не было записи, держать в списке резервных. Особенно если в качестве номера банка взять младьшие биты адреса блока.

                                                                                                                  Оптимизации разработчиков идут несколько в другом направлении, что сказывается на уменьшении паразитных нагрузок для записи мелких блоков.

                                                                                                                  Что за тайная оптимизация? Объединение нескольких логических записей в близкие сектора в одну физическую запись?
                                                                                                                  • 0
                                                                                                                    Что за тайная оптимизация? Объединение нескольких логических записей в близкие сектора в одну физическую запись?

                                                                                                                    нет. Введение понятий блок-апдейтов. Блоков, в которых хранятся лишь группы страниц для разных блоков, которые в трансляции частично заместят содержимое оригинального блока. Снижает паразитные нагрузки при записи.
                                                                                                                    Ещё полезная оптимизация — физические блоки, в которых вообще никогда не было записи, держать в списке резервных. Особенно если в качестве номера банка взять младьшие биты адреса блока.

                                                                                                                    Что-то вы про «номера банка» несуразное написали. Попробуйте переписать.
                                                                                                                    А ничего. В начале у нас кроме FAT ещё и корневой каталог. И просто каталоги. В итоге, если мы при ротации для блоков ниже 32 MiB будем выбирать наименее изношенный физический блок, а для остальных — более изношенный физический блок, то изношенные физические блоки у нас осядут в неизменяемых данных.


                                                                                                                    Счетчики записей для блоков (там где они есть и где известны) как бы не намекают на подобный алгоритм действий. Насчет «изношенные физические блоки осядут в неизменяемых данных» не получится. Например неизменяемые данные записаны на новую USB flash и до конца жизни накопителя никто их не перезаписывает. В итоге имеем неизменяемые данные в совершенно неизношенных блоках.

                                                                                                                    • –1
                                                                                                                      Про номера банков не поняли? А все просто. 0,4, 8, 12 логический блок — нулевой банк, 1, 5, 9, 13 — первый, 2, 6, 10, 14 — второй, 3, 7, 11, 15 — третий. А не так, что первый 2 мегабайта — все в нулевой банк. И это тоже оптимизация под FAT. она дает равномерное заполнение банков для заполненной не до конца флэшки.

                                                                                                                      Если этой оптимизации нет, то при заполненной на 20% флэшке у нас на FAT будет использоваться только нулевой банк. А на ext2 — заполнение диска более равномерное, так что такая оптимизация важна прежде всего для FAT.

                                                                                                                      Счетчики записей для блоков (там где они есть и где известны) как бы не намекают на подобный алгоритм действий

                                                                                                                      Помнится, в служебной информации были не опознанные вами биты. Не хранится ли там число потребовавшихся ECC-коррекций? И не является ли оно не менее важным, чем счетчик записей?

                                                                                                                      Насчет «изношенные физические блоки осядут в неизменяемых данных» не получится.

                                                                                                                      Любые процессы с флэшкой надо анализировать как вероятностные. Вы приводите частный случай. А для любого алгоритма есть частные случаи, когда все плохо. Для того делается моделирование, чтобы проверить, как алгоритм ведет себя на большом массиве типичных случаев.

                                                                                                                      Например неизменяемые данные записаны на новую USB flash и до конца жизни накопителя никто их не перезаписывает. В итоге имеем неизменяемые данные в совершенно неизношенных блоках.

                                                                                                                      Ну давайте попробуем подумать???

                                                                                                                      Ну скажем есть тысяча файлов по 2 мегабайта в каждом (128 кластеров). Пишутся они обычным образом: открыли, записали данные и закрыли. Это означает, что на каждый файл было 128 записей в FAT, 2 записи в каталог и 1 запись данных. Так что после первых 10 файлов — уже сильно выгодно изношенные блоки выдавать на «вечное хранение» под данные файла.
                                                                                                                      • 0
                                                                                                                        Про номера банков не поняли? А все просто. 0,4, 8, 12 логический блок — нулевой банк, 1, 5, 9, 13 — первый, 2, 6, 10, 14 — второй, 3, 7, 11, 15 — третий. А не так, что первый 2 мегабайта — все в нулевой банк. И это тоже оптимизация под FAT. она дает равномерное заполнение банков для заполненной не до конца флэшки.

                                                                                                                        говоря о физических банках, то показан разброс по микросхемам.


                                                                                                                        Говоря о логических банках


                                                                                                                        0x0-0x3C3*0x200000=именно столько логического пространства реализует нулевой банк. 0 блок из 1 банка — это уже 0x3C4 блок в логическом пространстве. Необходимость организации в банки — экономия на размере маркера номера блока (маркер с номером в служебке блока, дублирующая информация из транслятора и существует далеко не во всех служебках). В случае, если в данном SK6211 использовать FAT, то таблицы всегда будут находиться только в границах 0 банка. (И по факту находятся там).
                                                                                                                        Если этой оптимизации нет, то при заполненной на 20% флэшке у нас на FAT будет использоваться только нулевой банк. А на ext2 — заполнение диска более равномерное, так что такая оптимизация важна прежде всего для FAT.

                                                                                                                        как уже написано он и есть в нулевом логическом банке в случае SK6211, но есть контроллеры, для которых все пространство будет как один логический банк.
                                                                                                                        Помнится, в служебной информации были не опознанные вами биты. Не хранится ли там число потребовавшихся ECC-коррекций? И не является ли оно не менее важным, чем счетчик записей?

                                                                                                                        понимаете при перемещении данных в другой блок (а смена позиции логического блока происходит при перезаписи даже части информации), а старый блок исключается и очищается (полностью все биты установлены 0xFF) т.е. информации о качества чтения для этого физического блока не остается и смысла ее тащить в другой блок нет. Не исключено, что можно ввести счетчики количества коррекций согласно ЕСС, но тупиковое направление в силу того, что в современной TLC памяти коррекции будут чуть ли не в каждой странице блока (только что выпущенной памяти).
                                                                                                                        Любые процессы с флэшкой надо анализировать как вероятностные. Вы приводите частный случай. А для любого алгоритма есть частные случаи, когда все плохо. Для того делается моделирование, чтобы проверить, как алгоритм ведет себя на большом массиве типичных случаев.
                                                                                                                        в силу специфики деятельности я знакомлюсь с большим количеством разных контроллеров.Привел пример очень популярного алгоритма, который с незначительными нюансами можно видеть в массе других контроллеров.
                                                                                                                        Ну скажем есть тысяча файлов по 2 мегабайта в каждом (128 кластеров). Пишутся они обычным образом: открыли, записали данные и закрыли. Это означает, что на каждый файл было 128 записей в FAT, 2 записи в каталог и 1 запись данных. Так что после первых 10 файлов — уже сильно выгодно изношенные блоки выдавать на «вечное хранение» под данные файла.

                                                                                                                        и зачем? Если есть еще много блоков, в которые не было записей. А также откуда контроллеру узнать, что данные будут лежать мертвы грузом, а не будут активно перезаписываться?

                                                                                                                        • 0
                                                                                                                          Необходимость организации в банки — экономия на размере маркера номера блока

                                                                                                                          А с этим никто не спорит. Просто эффективней из LBF-адреса сектора под адрес банка выделить младшие биты. В минусах будет одинаковое количество блоков в банке.

                                                                                                                          тупиковое направление в силу того, что в современной TLC памяти коррекции будут чуть ли не в каждой странице блока

                                                                                                                          Тем не менее, по каким-то критериям блоки отправляются в список bad-блоков. И скорее всего эти критерии количественные, то есть позволяют выделить надежные и слабые блоки.

                                                                                                                          старый блок исключается и очищается (полностью все биты установлены 0xFF) т.е. информации о качества чтения для этого физического блока не остается

                                                                                                                          Её можно хранить в памяти контроллера. Правда встает вопрос о хранении между включениями — скорее всего в контролере нету своей флэш-памяти.
                                                                                                                          В целом аргумент про полное стирание — сильный.

                                                                                                                          откуда контроллеру узнать, что данные будут лежать мертвы грузом, а не будут активно перезаписываться?

                                                                                                                          А тут есть хорошая презумпция. Таблицы FAT — перезаписываться будут, остальные данные — скорее всего нет. То есть можем считать что первые логические 32 мегабайта — перезаписываются часто, остальное — редко. И в 99% случаев — будем правы.

                                                                                                                          и зачем? Если есть еще много блоков, в которые не было записей.

                                                                                                                          А вот это уже особенность ext2. У меня такое впечатление, что после записи 5-10 процентов на ext2 уже записаны все блоки. Дело в том, что ext2 борется с фрагментацией файлов путем рассредоточения их по диску. Плюс ещё старается разместить файлы поближе к каталогам. А каталогов — порядка тысячи. В итоге после записи каталоговой структуры — уже можно считать что большинство блоков записано. Это не FAT, где при создании каталоговой структуры все каталоги попадут лишь в несколько логических блоков.
                                                                                                                          • 0
                                                                                                                            А тут есть хорошая презумпция. Таблицы FAT — перезаписываться будут, остальные данные — скорее всего нет. То есть можем считать что первые логические 32 мегабайта — перезаписываются часто, остальное — редко. И в 99% случаев — будем правы.

                                                                                                                            нередкая ситуация: работа с файлом на USB flash. Какой-нибудь студент делающий реферат, один файл пересохранит многократно. При том что редакция будет незначительна и размер в кластерах прежний и положение в логическом пространстве прежнее. И таких ситуаций множество, когда надо думать не только о FAT таблицах, в связи с чем направления по оптимизации записи именно FAT таблиц как-то иначе, чем иные данные не получают широкого распространения.
                                                                                                                            А вот это уже особенность ext2. У меня такое впечатление, что после записи 5-10 процентов на ext2 уже записаны все блоки. Дело в том, что ext2 борется с фрагментацией файлов путем рассредоточения их по диску. Плюс ещё старается разместить файлы поближе к каталогам. А каталогов — порядка тысячи. В итоге после записи каталоговой структуры — уже можно считать что большинство блоков записано. Это не FAT, где при создании каталоговой структуры все каталоги попадут лишь в несколько логических блоков.
                                                                                                                            итог: паразитная нагрузка в случае Ext выше
                                                                                                                            Тем не менее, по каким-то критериям блоки отправляются в список bad-блоков. И скорее всего эти критерии количественные, то есть позволяют выделить надежные и слабые блоки.
                                                                                                                            как правило они отправляются технологическим ПО. Исключить блок из трансляции можно по многим критерями. Например по количеству попыток чтения с использованием Read Retry, после успешного прочтения, но с долгими мучениями переписать его в другой блок. Но есть ли смысл закладывания этих алгоритмов в обычные USB flash — большой вопрос.

                                                                                                                            Например у современных NAND микросхем, есть возможность в каждой плоскости по страницам исключать проблемные столбцы (Bad Column) и формировать список проблемных столбцов, где наиболее вероятно возникновение ошибок. Но производители не тестируют все микросхемы, часто информация об исключенных столбцах записанная в микросхемы ничего не имеет общего с реальными проблемными местами.

                                                                                                                            Технология производства выглядит как быстро, дешево и лишь бы кое-как работало.
                                                                                                                            • 0
                                                                                                                              Какой-нибудь студент делающий реферат, один файл пересохранит многократно. При том что редакция будет незначительна и размер в кластерах прежний и положение в логическом пространстве прежнее.

                                                                                                                              Мда… Знаете с времен редактора TED для RSX-11М много воды утекло. Никто не перезаписывает уже лежащий на диске файл. Делает так:

                                                                                                                              • Создали файл с новым, временным именем. Для Word имя этого файла начинается с тильды.
                                                                                                                              • Записали данные в него.
                                                                                                                              • Существующий файл переименовали в .bak
                                                                                                                              • Новому файл дали имя старого файла.
                                                                                                                              • Удалили .bak


                                                                                                                              Последние лет 30 — это основная технология, все остальные варианты — приводят к потере файла из-за сбоя во время записи.

                                                                                                                              итог: паразитная нагрузка в случае Ext выше

                                                                                                                              УВЫ. Итог — всего 4 записи на FAT взамен целых 4 записей на ext2. Но, как не обзови, 4=4.
                                                                                                                              • 0
                                                                                                                                УВЫ. Итог — всего 4 записи на FAT взамен целых 4 записей на ext2. Но, как не обзови, 4=4.
                                                                                                                                у Вас 4 запис, в силу Ваших знаний этого вопроса. Вы даже в FAT ошиблись и не учли процесс обновления FSinfo.
                                                                                                                                • 0
                                                                                                                                  Ну так расскажите тогда, сколько будет по вашему мнению.
                                                                                                                      • 0
                                                                                                                        Введение понятий блок-апдейтов. Блоков, в которых хранятся лишь группы страниц для разных блоков, которые в трансляции частично заместят содержимое оригинального блока.

                                                                                                                        Хорошая оптимизация, но сложная. Ну не поверю, что объединение двух логических передач данных в одну физическую запись не сделали раньше.
                                                                                                                        • 0
                                                                                                                          Хорошая оптимизация, но сложная. Ну не поверю, что объединение двух логических передач данных в одну физическую запись не сделали раньше.

                                                                                                                          подобное обычно на уровне драйвера ОС. Как например в жестких дисках уже много лет как введено понятие AHCI контроллера, который сортирует очередь команд для оптимизации перемещений БМГ. Буферизацию на запись с оптимизации записей для сменных устройствах обычно не используют. В силу того, что от пользователя можно ждать постоянных подвохов связанных с извлечением накопителя в неподходящий момент. USB NAND контроллер просто обслуживает R/W операции идущие поверх USB PHY и тут уже вопрос как обрабатываются команды. Учитывая, что в некоторых USB flash используются те же контроллеры что и в некоторых бюджетных SSD, то можно предполагать наличие классических оптимизаций. Но в случае простых контроллеров, так оптимизаций обычно нет.
                                                                                                                          • 0
                                                                                                                            Драйвер ОС не знает размера физического блока и ориентируется на размер кластера.

                                                                                                                            Тот же linux — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет. С другой стороны, не так важно, выдернем ли мы флэшку во время записи или во время буферизациии длиной в 1 микросекунду. Более 50 миллисекунд — буферизацию делать не стоит. А до 50 мс — это «вытащил ровно во время записи».

                                                                                                                            можно предполагать наличие классических оптимизаций

                                                                                                                            Ну я рад, что в каких-то вещах мы начинаем сходится.
                                                                                                                            • 0
                                                                                                                              Тот же linux — вообще не рассчитан на извлечение флэшки, у него иногда буферизация записи до минуты идет.

                                                                                                                              самый опасный момент. Выдернуть USB flash в момент, когда будет происходить запись оверлея трансляции и мгновенный трупик. Конечно на не факт, что на сотню выдергиваний удастся поймать момент, но тем не менее анализируя поток мертвых накопителей вижу немало случаев, когда это стало причиной смерти накопителя.
                                                                                                                              Драйвер ОС не знает размера физического блока и ориентируется на размер кластера.
                                                                                                                              тем не менее две последовательные записи он потенциально может объединить в одну, а дальше пусть NAND контроллер смотрит, пролезет все в один блок или нет.

                                                                                                                              • 0
                                                                                                                                Вот по личному опыту больше трупов я видел после стандартного извлечения с помощью «отключить устройство» в винде.
                                                                                                                                Не можете прокомментировать?
                                                                                                                                • 0
                                                                                                                                  Вот по личному опыту больше трупов я видел после стандартного извлечения с помощью «отключить устройство» в винде.
                                                                                                                                  Не можете прокомментировать?
                                                                                                                                  При изношенной памяти и сбоях при записи уже неважно как будет извлечен накопитель из USB порта.
                                                                                                                                  • +1
                                                                                                                                    Проблема в том что изучение показывало, что флешки были не самые изношенные офисной нагрузкой (не самые большие объемы документов на них таскалось, редко напрямую с флешек кто работал, в отличие от меня). Это было еще во времена массовости 1-4 гиговых флешек, проблем с записью и чтением до отключения не наблюдалось, а вот после отключения — аболютные трупы получались. Ну вот вообще абсолютные. То есть из разряда записали, скопировали обратно, отключили, вытащили, втыкают заново — труп. Разные утилиты не помогали.
                                                                                                                                    Особенно часто грешили кингстоны, купленные не в сомнительных местах, а в нормальных магазинах…
                                                                                                                                    В то же время и в хвост, и в гриву используемые мною годами, которые я вечно выдергивал сразу после записи (как индикаторы отмигаются) — обычно либо терялись быстрее, либо утрачивали актуальность объемов, а не дохли.
                                                                                                                                    • 0
                                                                                                                                      Индикаторы скорее всего показывают передачу данных, а не сам процесс записи. При штатном отключении записывается FSinfo. Отгадка скорее всего в том, что при выдергивании вы ждете пару секунд после окончания индикации, а при штатном завершении — ориентируетесь на клик мышкой, и в итоге попадаете как раз на операцию записи. Выжидайте пару секунд — и все будет нормально.

                                                                                                                                      Спасибо за красивый эффект, сам не знал, пока копаться не начал.
                                                                                                                                • 0
                                                                                                                                  Оверлей трансляции — это что за зверь?

                                                                                                                                  тем не менее две последовательные записи он потенциально может объединить в одну,

                                                                                                                                  Потенциально может, но зачастую путем потери во времени передачи данных. Например, при двух записях в FAT, вам придется передавать то, что находится между изменяемыми кусками.

                                                                                                                                  Потому реально — не объединяет.
                                                                                                                      • 0
                                                                                                                        Видите в чем беда… Вы перфекционист. Вам кажется, что если уж оптимизация — так до полного упора. А это просто не нужно. Есть такое правило «20-80» (20% людей выпивают 80% пива). 20% возможных оптимизаций дают примерно 80% эффекта.

                                                                                                                        И не надо анализировать бут-сектор и считать размеры FAT. Ну хотя бы потому, что 90% людей флэшку не переформатируют. А из оставшихся — 95% форматирует с дефолтными параметрами. И того, настройкой на дефолтную разметку мы оптимизируем 99.5% случаев использования.

                                                                                                                        Остальное — никому не нужный перфекционизм.
                                                                                                                        • 0
                                                                                                                          Видите в чем беда… Вы перфекционист. Вам кажется, что если уж оптимизация — так до полного упора. А это просто не нужно. Есть такое правило «20-80» (20% людей выпивают 80% пива). 20% возможных оптимизаций дают примерно 80% эффекта.

                                                                                                                          И не надо анализировать бут-сектор и считать размеры FAT. Ну хотя бы потому, что 90% людей флэшку не переформатируют. А из оставшихся — 95% форматирует с дефолтными параметрами. И того, настройкой на дефолтную разметку мы оптимизируем 99.5% случаев использования.

                                                                                                                          Остальное — никому не нужный перфекционизм.

                                                                                                                          именно введение оптимизаций для FAT можно назвать перфекционизмом. Такие попытки были. Например OTI 2169, там небольшой логический мини банк для блоков с FAT был. Но эта политика себя не оправдала. (это было во времена USB Flash 256Мб, 512МБ)
                                                                                                                          • 0
                                                                                                                            Ещё раз говорю — сделайте моделирование. И вы увидите, что алгоритмы оптимизированы под FAT.
                                                                                                                            • 0
                                                                                                                              Ещё раз говорю — сделайте моделирование. И вы увидите, что алгоритмы оптимизированы под FAT.
                                                                                                                              пока не получили массового распространения файловые системы учитывающие аппаратные нюансы NAND flash, то FAT остается файловой системой, которая имеет минимальную паразитную нагрузку. Чуть поглубже погрузитесь в устройство той же Ext и понаблюдайте за всеми R/W операциями и проанализируйте места записей и посчитаете насколько паразитных записей будет больше.
                                                                                                                              • +1
                                                                                                                                Что значит «не получили массового распространения»? UBIFS, JFFS2 и LogFS более чем используются. Вы попробуйте найти устройство с linux, где не было было бы одной из этих систем!

                                                                                                                                Но именно с микросхемами NAND flash, а не с USB-флэш, в которой для этого есть собственный контролер.

                                                                                                                                посчитаете насколько паразитных записей будет больше.

                                                                                                                                Я вам уже посчитал — аж 4 на ext2 взамен всего 4х на FAT для коротких файлов (размером меньше кластера). При этом ext2 агрессивно кэшируется, в отличие от FAT на windows. Иногда после записи на флэшку делаешь sync и чуть ли не минуту ждет сброса дискового кэша. Так что реальных операций записи — сильно меньше.

                                                                                                                    • –2
                                                                                                                      Причины того, что USB flash у вас умирали с использованием Ext совсем в другом.

                                                                                                                      И в чем же они? Почему 4 записи на файл на ext2 вам кажутся сильно больше, чем 4 записи на FAT?
                                                                                                • +3
                                                                                                  Возьмем к примеру USB Flash на старом контроллере и простой NAND
                                                                                                  SK6211 (UFD) + NAND K9HBG08U1M -2шт.

                                                                                                  Samsung NAND 8bit I/O, страница 2112 байт. 2 банка, 2 плоскости в банке. Микросхема умеет работать сразу с 2 плоскостями. Организация в блоки по 128 страниц. (128*2112=270336 байт).

                                                                                                  2 микросхемы = 4 банка, в каждом банке по 2 плоскости. Контроллер реализует эти возможности. В итоге имеем параллельную симметричную запись по каждому из каналов сразу в 4 банка и в каждом сразу в две плоскости. Итого поток сразу по 8 «каналам». 8*128=1024 страницы — это размер блока (1024*2112=2 162 688), единица в трансляции, которой оперирует данный NAND контроллер.

                                                                                                  Организация страницы: (особенность SK6211)
                                                                                                  2112 байт из них 2048 — данные для LBA диапазона. 64 служебные. по 16 байт на каждый блок 512 байт. В каждые 16 байт входят несколько служебных байт с маркером и флагами (дублирующие информацию из транслятора) и ЕСС (БЧХ)

                                                                                                  Трансляция:
                                                                                                  Логический банк по 0x400 (1024 блока), реально включено в трансляцию 0x3Cx (количестве в каждом экземпляре будет разное в зависимости от количества заведомо забракованных блоков).

                                                                                                  В таблице указываются порядковые номера блоков из которых формируется LBA диапазон.

                                                                                                  пример работы NAND контроллера:
                                                                                                  Допустим в блоке с логическим номером 3 лежит файл 2кб, мы его отредактировали и сохранили изменения. NAND контроллер прочитает целый блок 2МБ, внесет в буфере изменения в виде наших модифицированных 2кб очистит и перепишет целиком блок 2Мб, только вот при выборе куда записать не факт, что он выберет блок из котрого прочитал. Скорее выберет блок из тех, что не принимают участие в трансляции с меньшим значением счетчика перезаписей, выполнит в него запись содержимого буфера, отразит сие в трансляции. Аналогичные действия произведутся в областях содержащие метаданные файловой системы.

                                                                                                  На вопрос с чего я решил, что данный контроллер работает именно так отвечу демонстрацией примера моей древней работы по реверс-инжинирингу http://www.flash-extractor.com/forum_old/viewtopic.php?t=758 (первое же сообщение с описанием сбора логического образа из дампов полученных из микросхем). Там описан только алгоритм сбора образа с пользовательскими данными в рамках ПО существовавшего в 2008 году.
                                                                                                  • –1
                                                                                                    Честно говоря, я не знаю, что там было в 2008ом году. Насколько я помню — 1-2 гигабайтные флэшки тех времен довольно спокойно переживали посекторную запись.

                                                                                                    А я про современные флэшки на 8 и 16 гигов.
                                                                                                    • 0
                                                                                                      Честно говоря, я не знаю, что там было в 2008ом году. Насколько я помню — 1-2 гигабайтные флэшки тех времен довольно спокойно переживали посекторную запись.

                                                                                                      А я про современные флэшки на 8 и 16 гигов.

                                                                                                      Я специально взял в качестве примера старый накопитель как значительно более простой пример в пояснении принципов работы. И кстати его размер 8Гб. Думаю Вам бы не стало проще понять принцип работы NAND контроллеров, если бы я добавил всякие нюансы с зашумливанием данных с исключением столбцов по плоскостям, несимметричной записью по каналам, нюансы с использованеим «блоков-апдейтов» и т. п.
                                                                                                      • –1
                                                                                                        Некоторые из этих нюансов позволяют дать приоритет в надежности для начальных логических блоков.

                                                                                                        Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — S25FL256S
                                                                                                        • 0
                                                                                                          Некоторые из этих нюансов позволяют дать приоритет в надежности для начальных логических блоков.

                                                                                                          Если вы чего-то не нашли в конкретной прошивке — это не означает, что такого не бывает никогда. :-) Как подтверждение — S25FL256S

                                                                                                          каким боком приведенный пример flash памяти может относиться к USB Flash или различным CF, SD картам?
                                                                                            • +1
                                                                                              Ну значит такое качество у вас анализа было… :-)

                                                                                              Для оптимизации под FAT хватает того, что контролер считает, что часто перезаписываемая область находится в начале диска, а не в его середине или в конце

                                                                                              Скорее это не качество моего анализа, а Ваше незнание принципов работы накопителей на основе NADN flash. Дело в том, что адресное пространство не используется линейно. Есть понятие группировок NAND страниц в блоки из которых в трансляторе формируется логическое пространство (очень грубое упрощение). Так вот любой физический блок может выполнить любую логическую роль.

                                                                                              Эксперимент очень простой. Берете 5-10 неиспользованных флэшек разных моделей. Разбиваете на 2 раздела. Один — большой под FAT, второй в конце, 1-2 гига, под ext3. При попытке растарить на него почти гигабайтный архив — запись зависает примерно в половине случаев.

                                                                                              Ваш эксперимент с создание разделов в разных местах логического пространства ровным счетом ничего не показывает, кроме того, что в случае использования Ext на USB Flash они отваливаются при высокой нагрузке, что не лучшим образом характеризует качество изделий. Упреждая вопрос с кажущейся одинаковой нагрузкой в случае FAT и Ext предложу Вам обратить внимание на устройство файловых систем, чтобы понимать, какие метаданные файловой системы и куда пишутся, кроме непосредственно самих данных файла. Также обращаю внимание на то, что запись ведется преимущественно блоками (группа NAND страниц), т. е. перезапись метаданных Ext — это неслабая паразитная нагрузка, которая намного выше, нежели в случае FAT.

                                                                                              • –1
                                                                                                Так вот любой физический блок может выполнить любую логическую роль

                                                                                                Это не отменяет тот факт, что таблица FAT находится в начале логического пространства адресов.

                                                                                                Упреждая вопрос с кажущейся одинаковой нагрузкой в случае FAT и Ext предложу Вам обратить внимание на устройство файловых систем, чтобы понимать, какие метаданные файловой системы и куда пишутся,

                                                                                                Обычный режим для Windows — это частое (после записи каждого файла)обновление таблицы FAT. Причем для мелких файлов — меняется лишь один сектор в этой таблице. Винда обычно настроена так, чтобы выдергивание флэшке не привело к поломке FAT.

                                                                                                С другой стороны linux кэширует запись в служебные области, Причем время кэширования — достаточно велико.

                                                                                                Так что теоретически, при распаковке кучи мелких файлов, нагрузка на определенные сектора будет выше для FAT

                                                                                                Собственно можете сами попробовать писать секторами по 512 в начало и конец логического диска на USB. И сами увидите, что посекторная запись в конец быстрее вышибает диск.
                                                                                              • 0
                                                                                                Пес его знает.
                                                                                                Есть такая штука Raspberry Pi.
                                                                                                Штатная флэшка под нее разбита на два раздела. Сначала маленький FAT с несколькими текстовыми файлами настройки, а потом, кажется, Ext3 (точно не FAT), работает нормально, образ льется по dd нормально. Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода. Но и FAT (тоже постоянная запись с камеры, но не RPi) под большой нагрузкой умирает за примерно то же время.
                                                                                                • 0
                                                                                                  Под большой нагрузкой (постоянная запись с камеры) флэшка умирает примерно за полгода.
                                                                                                  потоковое видео, объем данных записываемых линейно достаточно велик. Накладные расходы на запись метаданных файловой системы невелики по отношению к размеру данных. При регулярной записи мелких файлов (как например при разархивации мелочи из архива), накладные расходы будут многократно выше и тип файловой системы сыграет роль.
                                                                                                  • 0
                                                                                                    Файлы от 1 до 5 мб недостаточно мелкие?
                                                                                                    Из-за особенностей настройки видео резалось именно такими порциями (низкое качество несколько секунд).
                                                                                                    • 0
                                                                                                      мелкий файл — это файл, который многократно меньше размера блока, которым оперирует NAND контроллер. 1-5Мб цифры одного порядка с размером блока.
                                                                                                  • 0
                                                                                                    Это не отменяет тот факт, что таблица FAT находится в начале логического пространства адресов.

                                                                                                    начисто отменяет. блок с boot сектором и FAT может и в самом конце быть. За время эксплуатации он постоянно будет перемещаться. Чуть ли не при каждой перезаписи. В первый свободный блок с существенно меньшим числом записей.
                                                                                                    Обычный режим для Windows — это частое (после записи каждого файла)обновление таблицы FAT. Причем для мелких файлов — меняется лишь один сектор в этой таблице.

                                                                                                    для вас меняется один лишь сектор, а NAND контроллер целиком переписывает блок.
                                                                                                    Винда обычно настроена так, чтобы выдергивание флэшке не привело к поломке FAT.
                                                                                                    от Windows и любой другой ОС тут мало что зависит. Если выдергивание произойдет во время обновления таблицы трансляции, то получите накопитель, который «перестал определяться» или «определяется нулевым размером».

                                                                                                    С другой стороны linux кэширует запись в служебные области, Причем время кэширования — достаточно велико.

                                                                                                    Так что теоретически, при распаковке кучи мелких файлов, нагрузка на определенные сектора будет выше для FAT

                                                                                                    Если не брать в расчет принципы работы конкретного NAND контроллера, то иллюзия подобная вашей имеет место быть. А по факту на Ext нагрузка будет выше.

                                                                                                    Собственно можете сами попробовать писать секторами по 512 в начало и конец логического диска на USB. И сами увидите, что посекторная запись в конец быстрее вышибает диск.

                                                                                                    поверьте, данный детский эксперимент мне точно нет нужды проводить. Я все же предпочитаю более глубокий анализ принципов работы NAND контроллеров.
                                                                                  • –1
                                                                                    А как повлиять на производителей в плане улучшения поддержки сторонних FS? Тут разве предусмотрена какая-то обратная связь? Даже просто выбрать при покупке модель с поддержкой ext3/ext4, если таковые вообще существуют в природе, и то практически невозможно, потому как в характеристиках этого не указывают. Поддержку основных кодеков и видеоконтейнеров укажут, а такую мелочь — нет.
                                                                                    • +6
                                                                                      А как повлиять на производителей в плане улучшения поддержки сторонних FS?
                                                                                      В том-то и дело, что они не сторонние, а нативные. В тех самых «приставках и телевизорах», в подавляющем большинстве случаев сидит Linux. А как влиять? Просить, требовать, искать прошивки, которые позволят вам использовать то, чего хотите. А как ещё?

                                                                                      Даже просто выбрать при покупке модель с поддержкой ext3/ext4, если таковые вообще существуют в природе, и то практически невозможно, потому как в характеристиках этого не указывают. Поддержку основных кодеков и видеоконтейнеров укажут, а такую мелочь — нет.
                                                                                      Ну вот эту проблему и нужно решать.

                                                                                      А то у вас получается, что Linux не поддерживает Linux'овые технологии — а виноваты разработчики. Нет. Виноваты те, что взял — и открутил эту поддержку по тем или иным причинам.
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    • 0

                                                                                      Нет, не понимаю. Сходить к соседу с внешним USB-диском с фильмами — вполне реалистичная ситуация (не у всех ещё интернеты в сотни мегабит). И форматировать его в «Ext4, XFS, Btrfs» совершенно не годится, потому что у соседа на компе стоит не Android-x86, а Windows 7.


                                                                                      На флешке/переносном USB-винте должна стоять ФС, которая работает одновременно и на приставках, и на телевизорах, и на виндах. Если сосед — хипстер/дизайнер, то и в макосях тоже.