Привет! А в апстриме форка exfat-nofuse давно нет обновлений?

Посмотри также тему "Не форкнутый ядерный драйвер EXFAT с поддержкой Linux 2.6, 3 и 4": Самсунг выкладывает исходные коды ядра Linux, используемые в их смартфонах, и там можно взять новый драйвер.

Я первый раз слышу про sdFAT. Это тоже ФС от Microsoft?

Ну и да, спасибо за патчи! У меня Linux 4.14, и я пользуюсь fuse-драйвером...

Интересно

• сколько лоровцев использует ядерный драйвер exFAT
• сценарии использования

Сам не использую exFAT никак (даже через fuse). Пытался — но телевизор не понимает. Либо vfat, либо ntfs.

Интересно

Мне другое интересно - сравнение его на тестах с fuse версией.

Такое ощущение, что на ПК от него толку нет.

А в апстриме форка exfat-nofuse давно нет обновлений?

Вот именно. В аппстриме пилили под ядра 2.*,3.*,4.* однако для текущего 4.15.7 оно уже не собирается.

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

Там есть под 4.15.7?

Я первый раз слышу про sdFAT.

sdFAT - коротко говоря идейный продолжатель exfat-nofuse. Фич больше и развивается.

С учетом того, что модуль не в официальном ядре… пилил его самсунг и в аппстрим так и не отдал… В общем не жди чудес.

Мне другое интересно - сравнение его на тестах с fuse версией.

Бери любой интерисующий тебя бенчмарк на выбор проконсультируйся с ZenitharChampion насчет деведёности патча до ума… ибо я по сути exfat-nofuse просто допилил под текущее ядро и немного пофиксил а возможности посравнивать разные реализации exfat-а у меня попросту нет. И как говорится успехов.

Такое ощущение, что на ПК от него толку нет.

От ядерных ntfs, vfat/fat сильно много толку?

>> Самсунг выкладывает исходные коды ядра Linux, используемые в их смартфонах, и там можно взять новый драйвер.

> Там есть под 4.15.7?

Я думаю что нет. Смартфоны Samsung обычно базируются на LTS-ядре - а какое оно сейчас? Для меня основной проблемой было узнать, какая модель телефона сейчас - самая распоследняя, чтобы затем найти на opensource.samsung.com исходные коды ядра. Причём по названию не ищется, надо какой-то буквенно-циферный код (на 4PDA можно найти).

Ещё злит что у них нет обратной связи. Я им как-то репортил баг через форму обратной связи на сайте. Мне даже не ответили (хотя обещали ответ в течение скольких-то там часов), но баг исправили.

> проконсультируйся с ZenitharChampion насчет деведёности патча до ума

А вот тут я не помогу :-( Я не проггер, я максимум - тестер. Когда я в прошлый раз утверждал, что форк оригинального драйвера на Гитхабе хуже оригинала, я базировался на общении с этим человеком, с которым мы общались по e-mail - в том числе и об этом. Которого, кстати, форк вполне себе устраивал! Это просто я - перфекционист.

Сейчас этот человек оффлайн. Да и баг, с которым он в тот момент столкнулся, уже может быть давно исправлен - ещё в каком-нибудь 2014!

>> Такое ощущение, что на ПК от него толку нет.

> От ядерных ntfs, vfat/fat сильно много толку?

Пользуюсь бесплатной версией Paragon NTFS уже несколько лет, даже забыл уже об этом. ФС жива :-)

На ПК нет. На mips использую.

Он выглядит как слегка патченый модуль vfat. Каковым и является.

Для тех кто всё ещё так и не понял что за [i]"новое i_version API"[/i] Ж)

modinfo exfat.ko
filename:       /usr/src/linux-4.16-bentoo/fs/exfat/exfat.ko
alias:          fs-exfat
version:        1.2.9
description:    exFAT Filesystem Driver
license:        GPL
srcversion:     33AE63A2C08ED9B3DC6EE9C
depends:
retpoline:      Y
intree:         Y
name:           exfat
vermagic:       4.16.0-bentoo SMP mod_unload modversions RANDSTRUCT_PLUGIN_d43ad165ccd7dfac11ee2f01249261442a5e320e677d31fbcc357534adc7b0f3

От ядерных ntfs, vfat/fat сильно много толку?

С ufsd от парагона скорость записи на USB3-хард у меня уверенно выше 50МБ/сек. ntfs-3g метров 20 в секунду выдаёт в лучшем случае.

Celeron N3150 вместо процессора, если важно.

С ufsd от парагона скорость записи на USB3-хард у меня уверенно выше 50МБ/сек

ключевые слова

от парагона

А вопрос был про ядерные /usr/src/linux/fs/ntfs и /usr/src/linux/fs/fat и не надо строить из себя альтернативно-умного. Потому-что я точно так-же могу сказать что у меня зашибись скорость ntfs в linux через вендаз в virtualbox/vmware смысл тот-же что и у тебя.

ZenitharChampion or any anonymous это exfat-1.2.19.tar.gz твой? можешь перевыложить но не на yadi.sk а хотя бы на https://gist.github.com ? потому-что крайняя версия с https://github.com/dorimanx/exfat-nofuse 1.2.9

Да, это мой. Выдрал из прошивки какого-то Samsung Galaxy два года назад. Затем внёс изменение в Makefile, чтобы оно компилилось (буковку Y поменял на M, в exfat-1.2.4.tar.gz можно посмотреть, как сделано там). Давно уже надо выдрать из исходников прошивки флагманского Самсунга - новую версию!

Версия 1.2.19 собирается максимум с Linux 3.16, но двумя патчами из exfat-nofuse можно поднять совместимость сначала до 4.1, потом до 4.4.

http://s000.tinyupload.com/index.php?file_id=81381851901116737495

Его ткнули в разницу между kernel mode и user mode, а тот обосравшись начал маняврировать «нищитова, я ни то имел в виду!!11». Пссс тебе на макушку из дуршлага.

anonymous во первых общеизвестно, что fuse* это намного медленнее чем ядерное просто потому что by design. Во вторых fat/vfat/ntfs в ядре сделан во многом вопреки. Что я имею ввиду см. хотя бы help к CONFIG_NTFS_RW и это емнип до сих пор не менялось с тех времён как вообще был запилен ядерный ntfs. В третьих как там обстоят дела в парагоне, вендазе либо где-то ещё в любом проприетарном, закрытом дерьме мне плевать. Точно так-же как и мне плевать на то, какой из сортов говна: fuse*, ядерный либо проприетарный в данном конкретном случае лучше просто потому что пользователи грёбаного вендаза обязаны страдать. На сим позвольте раскланяться. Щастячка, здоровячка и ваще всех благ.

Спасибки скачал. Сейчас сравню exfat-nofuse с гитхаба который 1.2.9 вот с этим который 1.2.19. Если в 1.2.19 сделали что-то нужное обновлю заплатку из шапки. И да заплатка из шапки и сейчас должна собиратся под всё начиная с 3.16 заканчивая 4.16 ;)

Они в 1.2.19 много перепилили но ощущение такое как-будто в 1.2.9 всё равно фич больше.

> Они в 1.2.19 много перепилили но ощущение такое как-будто в 1.2.9 всё равно фич больше.

Сообщество Open Source вносило свои фичи.

А вопрос был про ядерные

Так ты уточняй, что «ядерные» - это «из состава ядра», а не «не fuse».

альтернативно-умного

Потому-что
так-же
тот-же

Чья бы корова мычала.

Так ты уточняй, что «ядерные» - это «из состава ядра», а не «не fuse».

Уточнил. Уточнить какое именно ядро я имел в виду или не нужно?

Чья бы корова мычала.

Моя корова отличает ядерные от fuse* в отличие от…

А тему ты читаешь жопой. Ну ок.

Я про ядерный опенсорсный драйвер вообще не вспомнил! Он же всегда был RO.

А что такое exFAT?

Смотри. Вот был DOS. Вот были жёсткие диски на 20 и 40 Мб. Потом диски стали 100 и 200 Мб. Потом 512 Мб и всё, предел. Биосы 386-х больше не видят. Потом появились 486-е, диски на гиг и на два.

И тут кто-то заметил, что размер кластера растёт пропорционально размеру HDD. На харде на 512 Мб он был 512 байт, на харде на 1024 Мб он был 1024 байт, и так далее. Ещё в учебнике Фигурнова советовалось разбивать диск на разделы, чтобы не терять место.

Теоретически возможная потеря места при использовании FAT16

1 Гб - 10%
2 Гб - 20%
3 Гб - 30%
4 Гб - 40%

Майкрософт презентовала файловую систему FAT32, и удобный конвертер из FAT16. Вроде бы проблема была решена. Но спустя год-два выяснилось, что проблема была не решена, а отодвинута: теперь на винте на гиг размер кластера был 512 байт, на винте на 2 гига - 1024 байта, и так далее...

Стоило ради этого ломать совместимость с DOS 6.22? Спасибо хоть была системная дискета Windows 98 с DOS 7.

А потом все перешли на NTFS. Но лично я имел дуалбут 98/2000, и обе системы были на FAT32. Каждый - по 20 гигов. И как-то нормально было.

«Проводник» Windows XP умел показывать в «свойствах файла», сколько файл весит, и сколько занимает физически на устройстве. В этот момент я и разобрался, что за проблема такая. Например, весит 1,08 Кб, а на диске 4,00 Кб. Ну, или 52 Мб весит, 52,1 Мб занимает. Как видишь, для больших файлов не критично, а для множества маленьких - критично.

А потом появились флешки. Моя первая появилась у меня в 2003, и имела размер 128 Мб. Уже в 2009 моя флешка была 16 Гб.

Там был FAT32. Потому что NTFS на флешке не эффективен (хотя и возможен). И много-много лет всё было нормально: флешки - маленькие, вышеуказанная проблема - не критична.

В 2006 Майкрософт вдруг решил радикально решить проблемы FAT, и выпустил exFAT. Всё: теперь хоть сколько может быть размер раздела - места теряется минимум. Кроме того, exFAT умеет всякие флешко-специфичные опции: считать количество перезаписей каждого кластера (после сто тыщ миллионов перезаписей, кластер «умирает»), чтобы в самый замученный кластер записывать в самую последнюю очередь, когда 99% места уже занято. А ещё exFAT умеет ACL - не знаю зачем, на флешках от этого - только проблемы...

Ты сперва его каменты почитай.

И для полноты картины, ты забыл написать что во времена до выхода висты, после NTFS но задолго до exFAT, сракасофтовские ублюдки кормили всех сказками про новую, модную, молодёжную фс - выньФС с тегами и такой кучей фич что там даже предполагались помимо покера ещё и встроенные женщины с пониженной социальной ответственностью. Потом видимо что то пошло не так и фичу отложили до симьёрачки. А дальше сракасофт вообще сдулся. Видимо фс настолько великолепна что просто никто её не заслуживает.

ты про ReFS?

было такое себе winFS и в обещаниях там чего только не было

Судить о человеке по комментариям в интернете - глупо. Впрочем, это видно по твоим каментам.

Судить о человеке по комментариям в интернете - глупо.

А не судить ещё более глупо.

Впрочем, это видно по твоим каментам.

Гугл любой поисковик твой друг. И выяснить что такое exfat, при желании, не составит труда и это секунды затраченного времени. Значит либо тебе лень либо ты хотел вовсе не этого плюс к этому твои однообразные каменты и вот что и требовалось доказать.

Но я никому ничего не доказываю. Живи дальше в своём мирке.

требовалось доказать

никому ничего не доказываю

Живи дальше в своём мирке.

Привет. Со дня на день выйдет Samsung S10. Когда станет известно его кодовое имя (в формате SM-G970F), на https://opensource.samsung.com/ можно будет скачать его прошивку, воспользовавшись кодовым именем для поискового запроса. Я предлагаю выдрать оттуда наиболее свежий драйвер exfat :-)

Я предлагаю выдрать оттуда наиболее свежий драйвер exfat :-)

Привет и тебе ZenitharChampion. Я за этим не слежу. Но начинание хорошее.

В общем такое:

• Galaxy S10e - SM-G970F
• Galaxy S10 - SM-G973F
• Galaxy S10+ - SM-G975F

Но видать ещё не выходил.

Я тоже не могу выполнить поиск. Раньше мне удавалось найти архив с ядром именно таким способом.

Если пройтись по ссылкам то kernel-sdfat выглядит живым. Надо будет проверить.

G960F ищется, а G970F нет

Скачал исходники ядра из Samsung S9. Директории fs/exfat нет, но есть fs/sdfat. В Makefile поправил obj-$(CONFIG_SDFAT_FS) на obj-m, и начал компилировать:

make -C /lib/modules/3.17.1-0-desktop/build M=/home/zenitur/sdfat modules
make[1]: Вход в каталог `/usr/src/linux-3.17.1-0-obj/x86_64/desktop'
make[1]: Entering directory `/usr/src/linux-3.17.1-0-obj/x86_64/desktop'
  CC [M]  /home/zenitur/sdfat/sdfat.o
  CC [M]  /home/zenitur/sdfat/core.o
  CC [M]  /home/zenitur/sdfat/core_fat.o
  CC [M]  /home/zenitur/sdfat/core_exfat.o
  CC [M]  /home/zenitur/sdfat/api.o
  CC [M]  /home/zenitur/sdfat/blkdev.o
/home/zenitur/sdfat/blkdev.c: В функции «bdev_check_bdi_valid»:
/home/zenitur/sdfat/blkdev.c:99:4: ошибка: неявная декларация функции «sdfat_debug_warn_on» [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [/home/zenitur/sdfat/blkdev.o] Ошибка 1
make[3]: *** [_module_/home/zenitur/sdfat] Ошибка 2
make[2]: *** [sub-make] Ошибка 2
make[1]: *** [__sub-make] Ошибка 2
make[1]: Выход из каталога `/usr/src/linux-3.17.1-0-obj/x86_64/desktop'
make: *** [all] Ошибка 2

Вот исходники, можешь попробовать сам.

Ну примерно такая же фигня была и в последний раз когда я пытался тестировать sdfat. Хоть что-то не меняеться.

Я посмотрел код sdfat. В файле KConfig есть описание этого драйвера. Написано, что это драйвер не только для exFAT, но и для FAT 12/16/32 и VFAT. В том же файле есть такая вещь, как Default Codepage. Выставлено как 437. Похоже что это для FAT32 и старее. Но вдруг этот драйвер решил выставить этот параметр в том числе и для exFAT? Было бы ооочень плохо!

Я помню в Ubuntu 8.04 был такой прикольный баг. Я смонтировал раздел NTFS, и я вижу файлы «Documents and Settings», «WINDOWS» и так далее, но я не вижу папок, названных по-русски. Причём количество свободного места говорит о том, что файлы есть. Я перемонтировал с -o locale=ru_RU.UTF-8, и тогда всё появилось. Наверное, подошло бы и en_US.UTF-8. Суть в том, что по умолчанию какая-то другая кодовая страница была. Гугл говорит, что NTFS использует UTF-16.

Потом в NTFS-3G изменили кодовую страницу по умолчанию, это даже было в ChengeLog. Году в 2009. И тогда стало нормально. Даже если монтировать не через udisks, а «руками». Дааа, вспомнил, мне приходилось в Gentoo вносить правку в конфиг ntfs-3g для HAL, чтобы русские имена появились!

Лучше роди какой нибудь конвертор что бы русский шрифт из анси как бы в утф превращался , а крокозябры лучше не трогать

> конвертор что бы русский шрифт из анси как бы в утф превращался

Вот тут пишут, что такой конвертер встроен прямо в драйвер vfat в линуксе. Указываешь «codepage» своего региона (для России это 866), а «iocodepage» - это в какую кодировку выводить (koi8-r или utf8). Получается, что драйвер сам всё конвертирует

Как я понял, в exFAT используется codepage UTF-16, а значит, там нет проблем вообще. В NTFS - тоже UTF-16. Я надеюсь, что драйвер sdfat, который умеет как FAT32, так и exFAT, для первой выставляет charset 437, а для второй - UTF-16. Но бегло грепнув код, я не нашёл такого условия...