The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для ядра Linux предложен новый вариант драйвера exFAT, opennews (?), 15-Сен-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


34. "Для ядра Linux предложен новый вариант драйвера exFAT"  –4 +/
Сообщение от пох. (?), 15-Сен-19, 11:02 
мущина, мущина - проснитесь, вы обocpaлись!

ваша "дефрагментация" имела хоть какой-то смысл только в ms-dos. В современных операционных системах (где, внезапно, больше одного процесса читают одновременно больше одного файла) от нее один вред даже на rotational носителях, при том что с exfat почти всегда используются исключительно флэши - которым совершенно, абсолютно, феерически похрен на разницу между "прочитать двадцать секторов подряд" и "прочитать двадцать секторов вразнобой" - тем более что level wearing все равно из "подряд" сделает "не подряд".

> Интересно, зачем корейцу понадобилось выкидывать полностью все?

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

Ответить | Правка | Наверх | Cообщить модератору

41. "Для ядра Linux предложен новый вариант драйвера exFAT"  +/
Сообщение от Голубой гигант (?), 15-Сен-19, 11:13 
Ты не прав. На флешках, фрагментация не замедляет доступ. И даже наоборот, фрагментация там полезна, чтобы не использовать по многу раз одни и те же блоки. Поэтому и убрали дефрагментатор
Ответить | Правка | Наверх | Cообщить модератору

79. "Для ядра Linux предложен новый вариант драйвера exFAT"  +3 +/
Сообщение от Аноним (170), 15-Сен-19, 12:22 
За "не использовать по многу раз одни и те же блоки" отвечает ftl внутри контроллера флешки.
Ответить | Правка | Наверх | Cообщить модератору

136. "Для ядра Linux предложен новый вариант драйвера exFAT"  +/
Сообщение от пох. (?), 15-Сен-19, 15:36 
дефрагментатор, если ты не понял - сделал производитель, в том числе - флэшек.
А убрал - какой-то кореец, который в лучшем случае - на подхвате был.

А может и вовсе другой кореец. хрен их знает. все одинаковые или это один и тот же?

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

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

43. "Для ядра Linux предложен новый вариант драйвера exFAT"  +3 +/
Сообщение от хотел спросить (?), 15-Сен-19, 11:17 
> феерически похрен на разницу между "прочитать двадцать секторов подряд" и "прочитать двадцать секторов вразнобой"

xер ты угадал!
есть офигенная разница между sequential read and random 4K (даже для SSD)

чтение последовательно на SDD даст около 400-500 MB/s, а рандомное чтение мелкими кусками по 4K даст в лучшем случае 30-40 MB/s

NVMe: 2000-3000 MBs и 60 MB/s для 4K


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

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

60. "Для ядра Linux предложен новый вариант драйвера exFAT"  +3 +/
Сообщение от пох. (?), 15-Сен-19, 11:48 
> есть офигенная разница между sequential read and random 4K (даже для SSD)

и эта разница никак не связана с пресловутой "дефрагментацией". Ты бы еще по 128 байт читал.

потому что страница флэша - >=64k.

exfat об этом знает, и размер кластера у нее, если альтернативно-одаренный не лезет куда не просили - 256.

А sequential read в многозадачных системах - редкость (точнее, они и из random могут, если повезет, сделать sequential - префетчем, block reordering и так далее, но в линухе это все ниже fs, поэтому не слишком эффективно)

Ответить | Правка | Наверх | Cообщить модератору

183. "Для ядра Linux предложен новый вариант драйвера exFAT"  +1 +/
Сообщение от хотел спросить (?), 15-Сен-19, 19:33 
> и эта разница никак не связана с пресловутой "дефрагментацией". Ты бы еще по 128 байт читал.

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

> потому что страница флэша - >=64k.

если бы все было так просто, то fio с 64k в один поток читал бы также как и последовательно
но нет.. скорость раз в 5 меньше...
даже со страницами в 128-512K скорость меньше в 2-3 раза

так что то, что SSD намного менее страдают от фрагментации - это всем известный факт,
иопсы рулят

но не стоит говорить что фрагментация вообще не оказывает никакого влияния

Ответить | Правка | Наверх | Cообщить модератору

194. "Для ядра Linux предложен новый вариант драйвера exFAT"  –1 +/
Сообщение от пох. (?), 15-Сен-19, 20:20 
>> и эта разница никак не связана с пресловутой "дефрагментацией". Ты бы еще по 128 байт читал.
> я говорил что дефрагментации будет еще одним фактором, который будет мешать читать

да не может она им быть - пока ты читаешь целыми страницами флэша (и желательно - не забыв выровнять fs на границу страницы - кстати, винда-то это сделает - а вот ты сообразил? Я, кстати, хз как и чем это в линухе. У gpart есть параметр -a .)

> не получится чтение в том числе в пределах одной страницы

получится, у exfat страница помещается внутри кластера, а не наоборот.

> если бы все было так просто, то fio с 64k в один

тут явные проблемы с тестом. (еще может быть prefetch, но его вообще-то надо выключать - c этими носителями ты ничего на нем не экономишь, а теряешь время на чтении ненужного)
Ну и 64k - для exfat абсолютно неподходящий размер. Даже если в страницу попадешь (скорее нет).

> но не стоит говорить что фрагментация вообще не оказывает никакого влияния

не может. by design. Искать проблему надо в кэше, префетче, элеваторе. Все эти штуковины с флэшом лишние и катастрофически влияют на производительность.

Я, честно говоря, полагал что линуксы научились всю эту музыку выключать автоматически.

Ответить | Правка | Наверх | Cообщить модератору

211. "Для ядра Linux предложен новый вариант драйвера exFAT"  –1 +/
Сообщение от хотел спросить (?), 16-Сен-19, 04:13 
ды ты прям охуенен, а я такой тупой - даже дисковый кеш не чистил

сразу вспоминается популярный анекдот:

Журналист берет интервью у старца 145 лет:
- Скажите, в чем секрет Вашей долгожительности?
- Да нет ни какого секрета, за свю свою жизнь я ни когда ни с кем не спорил.
- Да ладно, не может такого быть!
- Ну не может, так не может...

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

результат моих многочисленных наблюдений говорит о том что я написал выше...
и скорость перестает отличаться от последовательного чтения, когда чтение происходит блоками не менее чем по 8MB
не нравится? я ошибаюсь? - ну ОК.. проходи мимо.

Ответить | Правка | Наверх | Cообщить модератору

213. "Для ядра Linux предложен новый вариант драйвера exFAT"  –1 +/
Сообщение от пох. (?), 16-Сен-19, 07:13 
> результат моих многочисленных наблюдений говорит о том что я написал выше...

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

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

Ответить | Правка | Наверх | Cообщить модератору

200. "Для ядра Linux предложен новый вариант драйвера exFAT"  +1 +/
Сообщение от x3who (?), 15-Сен-19, 21:14 
> флэши - которым совершенно, абсолютно, феерически похрен на разницу между "прочитать двадцать секторов подряд" и "прочитать двадцать секторов вразнобой"

Для таких как вы там специально даже картиночку повесили с тестированием скорости при последовательном и рандомном чтении.  

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

220. "Для ядра Linux предложен новый вариант драйвера exFAT"  +/
Сообщение от пох. (?), 16-Сен-19, 07:34 
и написали для таких как вы - что это _ramdisk_. Даже не nvme - ram! У тебя скорость доступа к оперативной памяти зависит от того, последовательно или случайно ты ее читаешь?
(зависит, на самом-то деле, но это не про "фрагментацию")

дальше - можно ковыряться в их тесте и искать, как, собственно, они добились таких уникальных результатов, особенно занятна разница между write и read (потому что должна была проиграть ext4, а мы видим обратное).

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

А если хочется добиться понимания, влияет ли фрагментация на производительность современных прямоугльных "дисков" и как - нужно делать совсем-совсем другой тест, и, главное - разбираться в его результатах и искать причины, а не мантры про "фрагментацию" бормотать.

тест, скорее всего, будет банален - открываем 500 файлов одновременно, и начинаем туда писать по 64k - последовательно в каждый, дергая flush каждый раз - и так по гигабайтику.
Дальше ищем инструменты (где-нибудь на винде, полагаю) - если они покажут, что ядро или кто там не смогло нас обмануть и файлы записаны в виде замысловато переплетенной вермишели (как оно, по идее и должно получиться, если драйвер не устроит какую-нибудь "оптимизацию" - но это придется именно проверять. Возможно придется close/open вместо flush делать)

Потом просто замеряем cat * > /dev/null - и сравниваем с таким же и из той же пачки диском, куда те же 500 записаны последовательно целиком. Если результаты не равны - ищем причину. Она НЕ в "фрагментации", она - в постановке эксперимента. Чудес - не бывает. Мыши из грязного белья не самозарождаются.

Ответить | Правка | Наверх | Cообщить модератору

239. "Для ядра Linux предложен новый вариант драйвера exFAT"  +/
Сообщение от x3who (?), 16-Сен-19, 22:37 
> и написали для таких как вы - что это _ramdisk_.

Для таких, как вы, они не только рам-диск тестировали.

Ответить | Правка | Наверх | Cообщить модератору

244. "Для ядра Linux предложен новый вариант драйвера exFAT"  +/
Сообщение от пох. (?), 17-Сен-19, 13:34 
ну то есть ты ТАКОЙ тyпой, что когда уже ткнули носом - не видишь очевидного?

> Для таких, как вы, они не только рам-диск тестировали.

и что?

P.S. впрочем, что я, действительно... поколение экспертов опеннета. Они именно феерически тупые и есть.
И да, в "не только рамдиске" тоже есть очень интересные (в смысле - демонстрирующие, что что-то определенно работало через задницу) результаты - но на фоне рамдисковых это семечки.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру