LINUX.ORG.RU
ФорумTalks

В ядре 5.8 скорость работы драйвера FAT вырастет в несколько раз

 , , ,


0

1

FAT File-System Driver For Linux Sees Patch To Run Multiple Times Faster

При тестировании на жестком диске, подключенном через USB, тест, который раньше занимал 383 секунды, завершается за 51 секунду.

. . . . .

И, чтобы два раза не вставать, The New Microsoft exFAT File-System Driver Has Landed In Linux 5.7

Драйвер от Samsung. Ими же представлен The exfat-utils 1.0.1 release.

Paragon отодвинули.

★★★★★

При тестировании на жестком диске, подключенном через USB, тест, который раньше занимал 383 секунды, завершается за 51 секунду.

Вот так, всю жизнь линуксоиды занимались FAT-шеймингом типа он тормозной (пример), а оказалось проблема не в FAT как таковом, тормозной это драйвер ленсука.

utf8nowhere ★★ ()
Последнее исправление: utf8nowhere (всего исправлений: 1)

Да, FAT32 прям тормозной в линуксах.

Как-то тестил на флешке — exFAT через FUSE был сильно быстрее в полном копировании со сбросом всего для безопасного извлечения (раза в два что ли).

fornlr ★★★★★ ()

вот почему так, когда оно уже никому не надо, они начинают заниматься оптимизацией и ускорять это дело.

какие нахрен флешки, они бы ещё компакт диски вспомнили и оптимизировали iso9660.

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

упоролись.

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

флешки ушли на пенсию

Что-то ты слишком модерновый. Ещё долго будут использоваться, хотя уже не так активно.

А так по разному бывает. Вон в KDE гораздо смешнее было в конце 2018 (!)

KDE научилось безопасно извлекать внешние HDD

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 2)

А можно ext4 также протурбить?

ChekPuk ★★ ()
Ответ на: комментарий от ChekPuk

Можно, турбь.

Делается там что-то постоянно, на самом деле.

EXT4 In Linux 5.6 To See Big Write Performance Boost For Direct I/O

Конечно, почти никого это не коснётся, но тем не менее, что можно, оптимизируется.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от fornlr

КДЕ раньше умел это делать, потом отвалилось. А потом с помпой вернули.

ChekPuk ★★ ()
Ответ на: комментарий от ChekPuk

KDE 3 умело гасить питание внешних HDD при извлечении этак до 2010 года?

Что-то я сильно сомневаюсь.

fornlr ★★★★★ ()
Ответ на: комментарий от Spoofing

технология ушла на пенсию
флешки

Почем резак для голокристаллов брал?

wxw ★★★★★ ()

Флешки, конечно не умерли но вот fat на флешках совсем не актуален.

aplay ★★★★★ ()
Ответ на: комментарий от aplay

А что там сейчас актуально, да ещё чтобы читалось и писалось везде?

imul ★★★★★ ()
Ответ на: комментарий от fornlr

Ещё долго будут использоваться

ага, с ntfs

crypt ★★★★★ ()
Ответ на: комментарий от Spoofing

может, из-за лицензий что-то поменялось. не так давно же сняли и патенты и майкрософт что-то там открыло. видимо, just-for-fun реверс был несовершенный. а теперь мы видим реализацию от проплаченных специалистов.

crypt ★★★★★ ()
Ответ на: комментарий от crypt

Бред. Как и про реверс.

Какой реверс? Ты о чём?

fornlr ★★★★★ ()
Ответ на: комментарий от fornlr

я честно не помню на память историю создания fat драйвера для linux. (да уже и не актуально)

crypt ★★★★★ ()
Ответ на: комментарий от crypt

Так в том и дело. Не путай технические проблемы с юридическими. Тем более там патент на длинные имена.

FAT простой как пробка. В линуксах его и сделали максимально просто по дубовому. Вот и всё.

fornlr ★★★★★ ()
Ответ на: комментарий от Spoofing

ладно, чтобы больше не было бреда, можно глянуть суть изменений

https://lore.kernel.org/lkml/87d08e1dlh.fsf@mail.parknet.co.jp/

был фиксированный префетч буффер. может, его еще в мохнатые годы во времена USB1.1 закодили. у автора патча дошли руки проанализировать ситуацию на современном USB и «медленном» 2TB винте. логично, что диск не флешка, на нем выгодно делать большой префетч. вот он проанализировал ситуацию и предложил механизм динамического сайзинга буфера.

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

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от fornlr

все-все. плохая память из-за бессонниц. то да се. ты меня убедил и я сходил посмотреть патч.

crypt ★★★★★ ()
Ответ на: комментарий от crypt

видимо, он единственный во всем мире.

Единственный во всем мире кто еще использует fat

aplay ★★★★★ ()
Ответ на: комментарий от aplay

в камерах до сих пор используется fat. автор японец. возможно, это как-то связано.

crypt ★★★★★ ()

В ядре 5.7 скорость работы драйвера FAT вырастет в несколько раз

It's too late for seeing it picked up in the 5.7 kernel but perhaps we'll see it for 5.8.

Читать свою ссылку ты, разумеется, не пробовал.

gremlin_the_red ★★ ()
Ответ на: комментарий от utf8nowhere

Вот так, всю жизнь линуксоиды занимались FAT-шеймингом

а улучшения-то касаются только HDD с FAT по USB, а не вообще.

crypt ★★★★★ ()
Ответ на: комментарий от BceM_IIpuBeT

exfat

Вы уж определитесь, актуально, или нет.

imul ★★★★★ ()
Ответ на: комментарий от utf8nowhere

пример

Там про фрагментацию. Тормоза от фрагментации никуда не денутся и не зависят от драйвера вообще. Как тормозило, так и будет тормозить.

тормозной это драйвер ленсука

Не тормозной, а неоптимальный на некоторых редких сценариях. Интересно, кстати, посмотреть на результаты в винде на упомянутом тесте. Что-то мне подсказывает, что оно даже предыдущей реализации сольёт.

gremlin_the_red ★★ ()
Ответ на: комментарий от crypt

А вот на счет свежих версий ядер на этих камерах я не уверен. То что автор японец объясняет многое.

aplay ★★★★★ ()
Ответ на: комментарий от fornlr

Что-то ты слишком модерновый

Здесь я с тобой соглашусь. Этот товарищ, похоже, ставит систему с помощью святого духа.

anti_win ()
Ответ на: комментарий от crypt

Компания Microsoft опубликовала технические спецификации на файловую систему exFAT и выразила готовность передать права на использование всех связанных с exFAT патентов для безвозмездного использования в Linux.

Примечательно, что раньше патенты на exFAT были ключевым звеном в большинстве претензий Microsoft, затрагивающих предустановку решений на базе Linux. Драйвер с реализацией exFAT шесть лет назад был открыт компанией Samsung под лицензией GPLv2, но он до сих пор остаётся не включён в основной состав ядра Linux из-за опасности предъявления компанией Microsoft иска о нарушении патентов.

https://www.opennet.ru/opennews/art.shtml?num=51374

greenman ★★★★★ ()
Ответ на: комментарий от aplay

Единственный во всем мире кто еще использует fat

fat - это единственный вариант, чтобы флешка (или диск) без проблем работали на любом устройстве. Не случайно в продаже флешки до сих пор форматированы в fat32 из коробки.

praseodim ★★★★ ()
Ответ на: комментарий от Spoofing

Работу с флопиками вот в 5.6 улучшили. Глядишь в 6.0 работу с перфокартами ускорят.

Deleted ()
Ответ на: комментарий от imul

Я уже без понятия про что там ОП пост, речь шла про ускорение работы драйвера FAT

aplay ★★★★★ ()
Ответ на: комментарий от wxw

Почем резак для голокристаллов брал?

Он в облаках витает.

atrus ★★★★★ ()
Ответ на: комментарий от fornlr

Не знаю на счёт KDE 3, но ранние версии KDE 4 в 2008-2009 (которые 4.0 != 4, да) точно умели отключать внешний HDD.

aquadon ★★★★★ ()
Ответ на: комментарий от praseodim

Ты хотел написать «fat - это единственный вариант, чтобы флешка (или диск) обязательно создала пользователю проблему с записью файлов большого размера».

gremlin_the_red ★★ ()
Ответ на: комментарий от gremlin_the_red

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

Вообще какие-то религиозные споры на ровном месте.

praseodim ★★★★ ()

год или два назад пытался записать на 8 гб флешку на фат32 файлы из debian... оно копировало от силы гига 3, причём всё медленнее и медленнее, потом вообще застывало...

хотя сейчас по 8 гб копирую на ту же флешку, норм...

buratino ★★★★★ ()
Ответ на: комментарий от gremlin_the_red

Тормоза от фрагментации никуда не денутся и не зависят от драйвера вообще. Как тормозило, так и будет тормозить.

Разве проблемы фрагментации не касаются только HDD? Ведь на SSD нет разницы между случайным и последовательным доступом, а значит, и фрагментация не должна влиять на производительность. Или я что-то не понимаю?

Serge10 ★★★★★ ()
Ответ на: комментарий от fornlr

гасить питание - это не задача десктопной среды, ничего не мешает залезть в рутовую консоль и сделать hdparm или что там

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Нет, как раз задача, это оно. Любая ОС (macOS, Windows, Linux с Gnome так делает). До KDE долго доходило.

ничего не мешает залезть в рутовую консоль

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

fornlr ★★★★★ ()
Ответ на: комментарий от gremlin_the_red

А за счет чего на всяких ext* нет такой проблемы?

cvs-255 ★★★★★ ()
Ответ на: комментарий от buratino

Проводки в фрешке прогрелись просто, вот и заработало как надо

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

За счёт другой организации. В FAT информация о всех кластерах хранится в одном месте. Кэшировать её ты не можешь (для терабайтного диска и размера кластера в 4к таблица получается размером в 1гиг), поэтому для получения адресов всех частей сильно фрагментированного файла требуется куча IO, и это мы ещё сам файл читать не начали. Более продвинутые фс грамотнее хранят метаданны, плюс имеют разные фишки для уменьшения фрагментации и её влияния на IO (настолько хорошие, что на ext4 на ssd фрагментация на скорость влияет никак).

gremlin_the_red ★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)