The OpenNET Project / Index page

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



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

Оглавление

Samsung предложил новый вариант драйвера exFAT для ядра Linux, opennews (ok), 21-Янв-20, (0) [смотреть все] +1

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


10. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 09:38 
Раньше каждый писал свой драйвер для fat. По причине относительной простоты, эта файловая система зачастую является одной из первых, поддерживаемых в новых операционных системах. А exfat, насколько я знаю, является всего лишь некоторой адаптацией той примитивной файловой системы под современные требования. Сравнивать с нормальными файловыми системами нет никакого смысла (я не утверждаю, что zfs нормальная).
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

14. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от X86 (ok), 21-Янв-20, 09:56 
Нормальные - это NTFS и EXT4
Ответить | Правка | Наверх | Cообщить модератору

22. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –4 +/
Сообщение от huechuec (?), 21-Янв-20, 10:42 
NTFS - нормальные... сударь... фи...
Ответить | Правка | Наверх | Cообщить модератору

73. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от НяшМяш (ok), 21-Янв-20, 13:49 
Относительно FAT - вполне себе.
Ответить | Правка | Наверх | Cообщить модератору

133. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (-), 22-Янв-20, 03:05 
А CDROM так очень даже ничего по сравнению с флопиком...
Ответить | Правка | Наверх | Cообщить модератору

117. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +4 +/
Сообщение от kernel_panic (??), 21-Янв-20, 18:17 
NTFS может сломаться только в том случае, если кто-то разобъёт HDD молотком.
А вот в линуксе так до сих пор и не завезли ни одной надёжной отказоустойчивой ФС.
А судя по высерам шизоида Торвальдса, это случиться ещё нескоро.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

129. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +2 +/
Сообщение от Антон (??), 21-Янв-20, 23:24 
не знаю, на практике ntfs ломалась несколько раз, а ext4 не выкидывала никаких сюрпризов. Это конечно не показатель, но это жизнь.
Ответить | Правка | Наверх | Cообщить модератору

131. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от White Human (?), 22-Янв-20, 01:19 
Как тебе это удалось? На винде много проблем, но только не с файловой системой.
Как правило, она живёт дольше, чем сам винчестер.
Ответить | Правка | Наверх | Cообщить модератору

142. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (-), 22-Янв-20, 03:26 
> Как правило, она живёт дольше, чем сам винчестер.

Не подтверждаю. В NTFS вполне возможно порушить MFT - и после этого вы таки пролетаете. Вообще совсем. Вплоть до BSOD при попытке монтирования. Или просто не цепляется. Хотя порой сторонние читалки и достают что-то - но вот это совсем не заслуга MS уже.

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

141. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 22-Янв-20, 03:24 
> NTFS может сломаться только в том случае, если кто-то разобъёт HDD молотком.

Да щас. Видал тут чудиков - убили нтфс, поюзав диск в компе с глючным RAM. Заметили они это когда MFT склеил ласты и восстанавливать стало тупо нечего... офигенно, чо.

> А вот в линуксе так до сих пор и не завезли ни
> одной надёжной отказоустойчивой ФС.

А вот btrfs кстати удалось запустить даже на совсем хламе сыпавшем бэдами, разложив данные со схемой DUP. Изредка чинит CSUM ERROR, но как тот еж - пищит, орет, но живет.

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

148. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от пох. (?), 22-Янв-20, 12:20 
вы разницу между бэдами (диск вернул ошибку - можно пытаться обработать ситуацию) и "глючным ram" вообще не понимаете?

Попробуйте поиграться на том, первом компе с btrfs - готов поставить вам двухлитровку жегулевского за статью о результатах. (мне на самом деле интересненько, но не более чем на два литра. Про zfs вот уже неинтересно, я знаю ответ.)

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

171. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 23-Янв-20, 15:21 
> вы разницу между бэдами (диск вернул ошибку - можно пытаться обработать ситуацию)
> и "глючным ram" вообще не понимаете?

Таки понимаю. Но CSUM ERROR он и в этом случае матюкается зачастую. По иной причине - походу мемтестом подрабатывает :P. Что починит и к тому же корректно - ни откуда не следует!

Но в NTFS это, как показали эксперименты, просто не замечают. До тех пор пока тому не настает совсем амба. Тогда, конечно, замечают. Но толку то? В лучшем случае можно сторонней коммерческой читалкой (оффлайн парсером) чего-нибудь выцепить попытаться. Канительно и результат весьма посредственный. В случае btrfs такой тулкит занахаляву в btrfs-tools встроен. Тупо единственный на все опенсорсные ФС. И чуть не единственный открытый тул такого класса.

> Попробуйте поиграться на том, первом компе с btrfs - готов поставить вам
> двухлитровку жегулевского за статью о результатах.

Дык попробовал, я любопытный и при удобных случаях подпихиваю btrfs'у всякую странную фигню отличную от идеала - а как раз посмотреть чего будет. Взял, прикололся, DUP сделал. Таки чинит "wrong csum" из копии. Для проверки фактической целостности - прикалывался над парой жирных торентов, в основном потому что их фактическая целостность проверяется тамошними хэшами и поэтому понятно - порушилось в результате или нет.

И таки в целом реально получить с ФС неубитый файл. Оно матюкается на csum error, идет во вторую копию, там обычно csum error уже нет - и по крайней мере по линии чтения с ФС все как бы относительно ОК. Правда в случае торента тот достаточно активно молотит сам по себе проверкой и csum в ram может не сойтись уже по линии его собственного sha опосля, при том это походу ошибка счета sha, ибо повторный пуск ничего в том месте не находит, даже если это из буфера а не с диска.

В общем это самый странный и извращенский self heal который я когда либо видел. Комбо стремное, но поведение забавное. Вот так - scrub идеально проезжает. А если оперативку погреть активным юзежом (хэшнуть торент несколько раз например) - вот вам csum error, corrected. Весьма забавные csum error-ы, в совершенно случайных местах, по всей площади, дважды в одно место не попадают. Однако в конечном итоге реально прохэшировать торент без ошибок :). Ну, если оперативка не глючит вообще с дикой частотой - иначе система в целом может быстро сдуреть, когда все виснет или падает - уже не до чексум торрентов малость, но вот это уже заметно.

> (мне на самом деле интересненько, но не более чем на два литра. Про zfs вот уже
> неинтересно, я знаю ответ.)

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

Ну и матерится в dmesg оно более чем достаточно для того чтобы проблему заметить. И счетчик в статистике файлухи накручивает. Пока прикалывался накрутил 520 csum error'ов. Ну блин, месяц мариновать ее я все же не буду, лениво. Поставил RAM менее агрессивные тайминги - торент проезжает успешно, csum error'ов при scrub нет - видимо bios и spd просто не поняли друг друга. Проверять насколько ему плохо будет если его на месяц так оставить - да ну его. Я интенсифицировал глюки насколько мог целенаправленным подогревом RAM, в обычном крейсерском режиме 520 сбоев копились бы фиг знает сколько, оно изредка глюкает при максимальной нагрузке, когда прогреется, а это ессно редкость. Что собственно и делает такие глюки сложными в отлове - мемтест вкалывающий по всей площади может не прогреть локально конкретный чип до максимально достижимых величин и вообще ничего не найдет - для этого надо более локализовано группу адресов активно долбить, чтобы все доступы одним и тем же чипам валились.

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

172. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 23-Янв-20, 15:29 
p.s. бонус по части убиения btrfs.

Сильнее всего я смог убить его когда поюзал карту памяти в ридере (довольно паршивую и стремную - по поводу чего и btrfs). Там в какой-то момент карта при записи словила клин и из комы за разумное время не вышла. Пришлось передернуть. Карта очухалась - но результат был довольно забавный. Два суперблока из трех - испарились. Включая дефолтный, так что лобовое монтирование сообщало про чексум еггог в суперблоке, "ctree open failed" - гудбай. Что как бы не прикольно.

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

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

173. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 23-Янв-20, 15:34 
> Таки понимаю. Но CSUM ERROR он и в этом случае матюкается зачастую.

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

Проблема что этот error будет где-то в логах, которые не факт что заметишь в тот же месяц. Хотя бы - месяц.
Что там будет в логах event viewer - я хз, у меня настолько гнилой техники под виндой все же не бывало.

Ну и эта ошибка - когда битые данные таки при чтении. А при записи никакого error не будет - будет контрольная инфа посчитанная с уже испорченного блока (если мы про машину с битой памятью) - так она и при чтении совпадет.

> Совсем очевидного дестроя вроде с наскока не вышло и фатально не развалилось

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

(для справок, существует образ zfs, который просто вызывает kernel panic. scrub'ом не лечится, а offline fsck у zfs нет. "Разработчики" из iX закрыли тикет со словами "а это не наша проблема". Получить этот образ нельзя, поскольку личная и коммерческая инфа, и размер недетский [по понятным причинам, он снят не zfs send], к сожалению.)

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

174. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от iZENemail (ok), 23-Янв-20, 17:16 
> (для справок, существует образ zfs, который просто вызывает kernel panic. scrub'ом не
> лечится, а offline fsck у zfs нет. "Разработчики" из iX закрыли
> тикет со словами "а это не наша проблема". Получить этот образ
> нельзя, поскольку личная и коммерческая инфа, и размер недетский [по понятным
> причинам, он снят не zfs send], к сожалению.)

Оффлайновый fsck у ZFS есть и называется zdb. Вот там можно поковыряться над битым образом, что называется "от души".

У Z-пула есть фича монтирования на предыдущую закрытую группу транзакций, когда обычное не помогает:
zpool import -F <poolname>.
"Поддержка команды "zpool import -F", позволяющей перемотать поврежденный пул к состоянию, соответствующему более ранней группе транзакций, что позволяет с высокой вероятностью восстановить повреждённый пул из состояния FAULTED."

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

177. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 23-Янв-20, 20:10 
> Оффлайновый fsck у ZFS есть и называется zdb.

Хороший такой fsck - не умеющий писать. Он не способен решить ни одной проблемы, тем более автоматически. Это не то что не fsck, это даже не dchek 70х годов. Включая хотя бы банально понять причину паники. (хотя, возможно, и мог бы помочь проследить ее до потрохов zfslib, только его тогда самого пришлось бы в отладчике запускать)

Тот пул импортируется (собственно, владельцу было некуда деваться и он год так с этим пулом и жил). scrub виснет. Попытка обращения к определенным файлам - kernel panic. closed, notabug.

Вот такие альтернативно-одаренные разработчики в iX. У них 100% воспроизводимый крэш - notabug, не повод даже точно определить, где крэшится.

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

201. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (201), 24-Янв-20, 00:38 
> потрохов zfslib, только его тогда самого пришлось бы в отладчике запускать)

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

> Вот такие альтернативно-одаренные разработчики в iX. У них 100% воспроизводимый крэш -
> notabug, не повод даже точно определить, где крэшится.

А как они его воспроизводить в своих пенатах должны? :)

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

198. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 23-Янв-20, 23:55 
> ну, собственно, следующее же действие в этом случае - вырубать питание, может
> даже - без шатдауна, и разбираться, что повредили и чему тут
> на диске вообще доверять можно.

Можно для начала readonly remount сделать, чтоли.

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

> Проблема что этот error будет где-то в логах, которые не факт что
> заметишь в тот же месяц. Хотя бы - месяц.

Для себя я иногда посматриваю статистику девайсов. Там счетчик csum error'ов есть.

> Что там будет в логах event viewer - я хз, у меня

Изначально, наверное, ничего: NTFS же не хранит чексумы? Значит и не заметит ничего этакого с наскока. Когда-нибудь дестрой доберется и до метаданных, вот там уже возможны варианты. Но вариантом может быть и немоунтабельный том или bsod в ntfs.sys. Видал такое несколько раз. Очень ценные данные сторонними читалками бывает можно вынуть порой, но вот это уже не заслуга MS.

> настолько гнилой техники под виндой все же не бывало.

К счастью это не у меня :D но мне было любопытно подсунуть btrfs'у что-нибудь стремное.

> с уже испорченного блока (если мы про машину с битой памятью)
> - так она и при чтении совпадет.

Да, и поэтому постепенно данные могут загадиться если их перезаписывать. А по идее и метаданные. Так что это потрошеный окунь в живой воде. Но тут еще фокус в том что хеширование торента грело RAM, провоцируя глюки в более приличном количестве. Простая запись в этом плане намного менее "токсична".

> ну ок, будем считать, что хотя бы частично тест прошел.

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

> (для справок, существует образ zfs, который просто вызывает kernel panic. scrub'ом не
> лечится, а offline fsck у zfs нет.

Хе, прикольно. Я бы сказал так:
1) Если бы у меня был такой образ, я бы его разработчикам btrfs показал, если там нет ничего ужасного. Если невозможно/не вышло минимизировать - трейс кернельного факапа как минимум.

2) Снесенные суперы лично я возвращал btrfs rescue super-recover. Прикольно что они такие предусмотрительные в тулсах.

3) Если everything has failed, btrfs restore можно вычитать все что читается без монтирования. Потыкав в разные точки входа деревьев, если дело совсем тухляк. Это как те коммерческие офлайн читалки совем убитого ntfs для винды. Только сразу родным тулкитом ФС. По-моему круто придумано :)

4) Кстати, идея: цепануть образ к _виртуалке_ и дать разработчикам полазить в ее памяти/продебажить? Образ им для этого слать не надо. И даже если отдебажат в хлам - так тестовую виртуалку же, а не хоста. И много инфо не сопрут, особенно с упавшим ядром :D

IIRC, qemu умеет дебагсервер для gdb вывешивать. Живость ядра там до лампочки: gdb будет с qemu общаться, а тот живой. То-есть как-то так: qemu-system-x86_64 <whatever crap> -gdb tcp::1234 и пробросить девам TCP-порт 1234. При конекте на него их gdb прицепится к VM и сможет дебажить ее сколько влезет. Это правда подразумевает готовность засетапить нечто странное и желание девов поиграть в очень странную игру с драньем зубов по телефону. Но вроде так можно и почему это не будет работать - я не придумал. Так что это скорее вопрос желания сторон пободаться с проблемой в очень странном формате.

> нельзя, поскольку личная и коммерческая инфа, и размер недетский [по понятным
> причинам, он снят не zfs send], к сожалению.)

А как тебе вон тот способ подбить автомобилем вертолет? Никак не могу придумать почему бы это не сработало. И образ слать никуда не надо...

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

20. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –11 +/
Сообщение от пох. (?), 21-Янв-20, 10:27 
ext4, если ты не в курсе - "является всего лишь некоторой адаптацей под современные требования" разработки, на десять лет старшей чем fat. Причем не сказать что чем-то лучшей или более надежной даже - скорее несущей груз совместимости с оборудованием, которое уже в 80е годы было мертво, и который не стали воспроизводить в microsoft.

Сравнивать с  нормальными системами, на идеях начала 90х, а не начала 70х, действительно, никакого смысла.

И тем более - с системами на идеях начала 2000х, когда компьютеры перестали быть большими и стало можно многое недоступное до того.

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

21. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 21-Янв-20, 10:34 
Только ext4 эволюционировала очень сильно. Более современные, может, и имеют возможности поинтересней, но не отличаются надёжностью и производительностью. На сегодня на роль универсальной фс общего назначения у ext4 нет конкурентов, поскольку она лучше во всём одновременно. Для флешек с ограниченным ресурсом f2fs поинтересней остальных вместе взятых будет правда.
Ответить | Правка | Наверх | Cообщить модератору

24. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 10:50 
> Только ext4 эволюционировала очень сильно.

fat тоже немножко отличается от msdos v1.0, но вы этого предпочли не видеть

> Более современные, может, и имеют возможности поинтересней,
> но не отличаются надёжностью и производительностью.

угу, конечно же, это ж не на ext4 "silent corruptions", это ж на zfs, или, там, ntfs ?

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

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

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

> у ext4 нет конкурентов, поскольку она лучше во всём одновременно.

от того что вы бубните эту мантру - устаревшая на двадцать лет fs не сделается "лучше во всем" ни на копейку.

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

25. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 10:59 
>если только не отключить к чертям журнал

Если отключить журнал, производительность упадёт раз в 100. Привет. Да и ничего особенного, будет ext2 с надёжностью примерно как у fat32. Барьеры отключать суицид конечно, это фактически основной оплот её надёжности, но journal_data_writeback ­вполне безопасно использовать, я проверял неоднократно. От lazytime потенциальных проблем едва ли не больше. Только fsck прогонять всё же придётся после жёстких выключений.

>Производительность там тоже не айс

Производительность на одном уровне с ntfs (наиболее быстрой и производительной фс), надёжность и безопасность на порядки выше.

>как она на самом деле должна работать

Я знаю, как она работает, и этого вполне достаточно.

>устаревшая на двадцать лет

Ммм это ложь. Не стыдно?

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

27. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +4 +/
Сообщение от пох. (?), 21-Янв-20, 11:03 
> Если отключить журнал, производительность упадёт раз в 100. Привет.

лол. Дальше можешь не продолжать.

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

29. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 11:07 
> лол. Дальше можешь не продолжать.

Я проводил различные эксперименты на ssd, это так, вся производительность ext4 зависит от журнала.

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

31. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Джафар (?), 21-Янв-20, 11:13 
Очередной "эксперт" с Opennet.
Ответить | Правка | Наверх | Cообщить модератору

33. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 11:18 
> Очередной "эксперт" с Opennet.

Факты вещь упрямая, бро.

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

37. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от пох. (?), 21-Янв-20, 11:32 
когда факты противоречат логике и здравому смыслу - разумный человек начинает искать проблему в постановке эксперимента.

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

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

40. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 11:42 
>волшебным образом в 100 раз производительней.

К чему придираться придираться к словам? Больше аргументов нет? Это называется художественный приём.

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

143. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 22-Янв-20, 03:28 
> Факты вещь упрямая, бро.

А фактовед знает про FTL, GC и прочие чудеса? Стократная разница - она стабильно держится? А то два запуска одного и того же на SSD/SD/usb флехах/... совершенно не обязаны отработать за одно и то же время :)

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

38. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от pda (?), 21-Янв-20, 11:34 
И вы хотите сказать, что с *отключенным* журналом ext4 работает *медленнее*, чем со включенным?
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

39. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 11:41 
Именно так. Например, доступ к файлам происходил значительно медленнее. Скорость передачи тоже была не стабильна. Сейчас не скажу, что мне больше не понравилось, результаты тестирования чтения или записи, но вывод был совершенно однозначный: фантазиям из интернета про отключение журнала лучше не верить. При этом, есть возможности, действительно влияющие на производительность.
Ответить | Правка | Наверх | Cообщить модератору

44. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +4 +/
Сообщение от Анонимм (??), 21-Янв-20, 12:04 
Так вот кто тесты на phoronix делает :)
Ответить | Правка | Наверх | Cообщить модератору

47. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 12:10 
> Так вот кто тесты на phoronix делает :)

Не совсем. Фороникс проводит странные синтетические тестирования различных синтетических бенчмарков на странном железе. Я среди прочего выполнял тестирование в реальных условиях на реальных данных, упирающихся в io, для чего и был приобретён ссд тогда и для чего это всё и затевалось, поэтому общего тут мало.

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

52. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 12:36 
методология - да, сходная.

В смысле - "главное не пытаться разбираться, почему результаты именно такие".

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

58. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (10), 21-Янв-20, 13:10 
> методология - да, сходная.
> В смысле - "главное не пытаться разбираться, почему результаты именно такие".

По крайней мере данные результаты легко объяснить. Функции ext4 завязаны на журнал, без него она дефективна. Такое объяснение выглядит крайне логично, я тоже долгое время верил что отключение журнала может чем-то помочь. Но потом сравнил (несколько раз в различных условиях) и пришёл к определённым выводам. Если бы это был рабочий способ повышения производительности, то им бы пользовались все, ведь внезапное отключение это призрачная угроза.

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

61. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 13:22 
> По крайней мере данные результаты легко объяснить. Функции ext4 завязаны на журнал,

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

У вас - "боженька устроил".

> без него она дефективна. Такое объяснение выглядит крайне логично, я тоже

оно выглядит совершенно алогично. Главное - верить.
И ни в коем случае не искать проблему в построении своих тестов.

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

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

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

64. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +2 +/
Сообщение от Аноним (10), 21-Янв-20, 13:25 
Мань, 15 лет назад ext4 не было и она не могла использоваться в продакшене. Я не понимаю, зачем отрицать очевидное и обвинять меня в некомпетентности в каждом ответе, при этом не предоставляя совершенно никаких аргументов.
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

70. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 13:42 
> Мань, 15 лет назад ext4 не было и она не могла использоваться в продакшене.

назови десять принципиальных отличий между той ext4 которая была пятнадцать лет назад и тогдашней ext3 "уже почти совсем но немного уже готовой для продакшна".

Особенно смешно - учитывая что обе получены cp -R ext2 ext$n+1

"аргументы" вида "да exfat то же самое что fat32" мы уже от тебя видели.

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

76. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 14:02 
>десять принципиальных отличий между той ext4 которая была пятнадцать лет назад

Логика работы экстентов и организации свободного места (фрагментация), совершенствование журнала и внедрение барьеров (что значительно повысило устойчивость перед отключениями), добавление верификации метаданных и оптимизация доступа к данным, среди прочего инлайнинг файлов и директорий (что также значительно повышает производительность), ускорение процесса восстановления (без негативных сайд эффектов в виде рассыпавшихся данных), эффективность работы на больших массивах данных (20 терабайт на диск сегодня уже не фантастика), продолжать можно долго, но почему это я должен что-то доказывать? Если ext3 и была "ext2 с журналом", то ext4 — уже совершенно другая система.

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

81. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 14:58 
>>десять принципиальных отличий между той ext4 которая была пятнадцать лет назад
> Логика работы экстентов и организации свободного места (фрагментация), совершенствование
> журнала и внедрение барьеров (что значительно повысило устойчивость перед отключениями),

барьеры появились сильно постфактум - и я хорошо помню, что именно привело к их появлению.
Нет, у ext2 этой проблемы в таких масштабах не существовало.

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

а это и тем более сильно позднее.

То есть все это - мелкие постепенные улучшизмы, большей их части в пресловутом 2005м, когда сделали cp -R - не существовало. flex_bg, dir_index, sparse_super - все это тоже появилось потом.

Структура fs осталась ровно та же - никаких революционных изменений, типа замены линейного списка битмэпами, так почему мне фанатики рассказывают что эти - разные, а вот fat весь одинаковый?

> доказывать? Если ext3 и была "ext2 с журналом", то ext4 —
> уже совершенно другая система.

про ext3 ее фанатики говорили примерно то же самое примерно в том же самом 2005м. А вот разработчики говорили другое - "ну да, конечно, есть ньюансы, но пользоваться ext2 мы тебе не советуем - вот посмотри на этот и этот патчи - их когда-нибудь кто-нибудь бэкпортирует туда, но не мы и не сегодня".
Гугль, естественно, бэкпортировал - и продолжал ее пользовать, кажется, по 2010й, но в паблик эти патчи не попадали. В 10м мигрировал на ext4 без журнала - и, подозреваю, до сих пор там.

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

104. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анонимун (?), 21-Янв-20, 17:49 
Ну и какую-же волшебную ФС ты нам противопоставишь?
А на счет тестов с отключением журнала я вполне верю, чего на свете не бывает.
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

128. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от хотел спросить (?), 21-Янв-20, 22:46 
главное верить что ext3 и ext4 ничем не отличается ))

пох ты реально троль

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

149. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 22-Янв-20, 12:28 
принципиально - разумеется, ничем (вообще-то это считалось плюсом, а не минусом). Код - разный, писали разные люди в разное время, и общий первоисточник - код ext2 лохматых времен, структуры данных - те же.

То есть если вы поотключаете новомодные фичи ext4, и отломаете проверку в драйвере ext3 - он с грехом пополам и парой паник - кое-что с нее прочитает.

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

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

175. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 23-Янв-20, 17:46 
> По крайней мере данные результаты легко объяснить. Функции ext4 завязаны на журнал,
> без него она дефективна.

EXT4 это такой EXT2 + журнал + хеширование дир + экстенты + delayed alloc. Если так, по большому счету. Об этом догадывается даже спиди-гонщик пох. Который, кстати, что-то имеющее отношение - кодил, если не ошибаюсь. Втирая ему про функции - не боишься ламернуться? Сорц то читал, покажешь пруф своего заявления хоть в каком фрагменте кода EXT4? У меня дерево сорцов есть и я проверю, чисто из любопытства. Мне на уровне технологий интересно как можно что-то тормознуть перестав работать с журналом.

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

Предложенное объяснение - никуда не годится! Потому что ничего не объясняет на уровне которых проглотили бы те кто хоть немного понимает как ФС работает. Пох едко и популярно это объяснил.

> Такое объяснение выглядит крайне логично, я тоже долгое время верил что отключение
> журнала может чем-то помочь.

Оно и помогает. Просто по дефолту ext4 журналит только метаданные. В обычных ворклоадах это не такой большой % - разница маргинальная. Но в ряде случаев можно упереться в интенсивную работу с метаданными, и там разница может стать ощутима. Ну например попробуй создание/удаление разлапистых иерархий на время. Только учти кеши, GC в ssd и все такое прочее, мерять заскоки фирмвари накопителя или крутизну кеширования не интересно в этом контексте.

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

> Но потом сравнил (несколько раз в различных условиях) и пришёл к определённым выводам.

Определенные выводы насчет дефолтного журналирования ext4 - простые: в обычном случае он не слишком то и мешает. Но вот путь к этом выводу и объяснения наблюдаемого - на уровне шамана с заячьей лапкой.

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

Гугл IIRC без журнала на серверах. Но тут надо понимать что это - гугл. У них там оверлейная мегаструктура поверх этого натянута и дело сервака - пулять запрошенные данные в сеть, да побыстрее. А если они окажутся битые или потерянные - с этим другие алгоритмы на других уровнях разберутся. Зато им так совершенно пофиг если сервер сдохнет или заглючит. И зачем им при этом супернадежность? Она по другому делается. Сие впрочем не означает что вы сможете так же.

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

178. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 23-Янв-20, 21:25 
Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2 и в 1.5 раза ext2? И ext3 в 1.2 раза быстрее ext2? На этот раз я использую максимально близкие к реальности цифры. Кеширование интересно в контексте журнала и повышения производительности связанным с кешированием журнала. Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых файлов — если они обнаружены, это повод задавать вопросы. А внезапные отключения ему не грозят.
Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

179. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 23-Янв-20, 21:27 
>ext4 в 2 раза быстрее ext2 и в 1.5 раза ext3

selffix

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

181. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 21:30 
> Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2
> и в 1.5 раза ext2? И ext3 в 1.2 раза быстрее
> ext2? На этот раз я использую максимально близкие к реальности цифры.
> Кеширование интересно в контексте журнала и повышения производительности связанным с кешированием
> журнала. Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых
> файлов — если они обнаружены, это повод задавать вопросы. А внезапные
> отключения ему не грозят.

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

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

187. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним84701 (ok), 23-Янв-20, 22:01 
> Попробуй провести свои эксперименты на старых добрых хардах, предварительно подготовленных затиранием блинов нулями.

Упор, я так понимаю, тут на "старых" -- т.е. без (device-managed) SMR? ;)


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

188. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 22:03 
>> Попробуй провести свои эксперименты на старых добрых хардах, предварительно подготовленных затиранием блинов нулями.
> Упор, я так понимаю, тут на "старых" -- т.е. без SMR? ;)

Разумеется. Причём лучше взять не более терабайтных по объёму, и таких, про которые известно, сколько внутри блинов и какие обнаружены баги у фирмвари. ;)

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

199. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 24-Янв-20, 00:25 
> Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2

У ext4 относительно ext2 в активе как минимум:
+экстенты.
+хэширование дир.
+delayed alloc.

И все это было явно не для красоты.

> и в 1.5 раза ext2?

Это повтор предыдущего вопроса. Я сорвал анониму стэк?
Если это было про ext3, то у ext4
+экстенты
+delayed alloc

> И ext3 в 1.2 раза быстрее ext2?

2vs3:
+хэширование дир
Может какие-то еще оптимизации которых я не помню или не знаю.

> На этот раз я использую максимально близкие к реальности цифры.

Эти цифры ... очень зависят от паттернов доступа. К ним есть разумные предпосылки в виде фич новых версий ФС.

> Кеширование интересно в контексте журнала

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

> и повышения производительности связанным с кешированием журнала.

...?

> Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых
> файлов — если они обнаружены, это повод задавать вопросы. А внезапные
> отключения ему не грозят.

Если это про гугла - они просто все сделали иначе. Есть "распределенный алгоритм" который этим занимается. Гугловское добро не идет к ФС и не просит дать файл, оно просит распределенный алгоритм вынуть данные. Тот делает запрос к какому-нибудь серверу из подходящих. Тот отдает данные. Или не отдает. Или отдает битые. В первом случае ок, в втором и третьем запрос будет повторен на какой-нибудь другой сервер.

Такие вещицы могут оперировать даже не чексуммами а скорее хэшами и это не только чексум но и способ адресации. Основы таких штук гуглятся по словам типа content addressable network. Где-то рядом можно познакомиться с каким-нибудь ipfs...

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

180. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 21:27 
> Мне на уровне технологий интересно как можно что-то тормознуть перестав работать с журналом.

Он же на SSD ставил свои странные опыты. Это ненаучно. Надо было проводить тесты на предсказуемых и понятных HDD с хорошо известными характеристиками, висящих на каком-нибудь стандартном и хорошо известном интерфейсе. А у SSD невесть что на уме у контроллера в любой момент времени и в каком реально состоянии те ячейки.

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

191. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 23-Янв-20, 22:21 
>что на уме у контроллера в любой момент времени и в каком реально состоянии те ячейки

Если бы это было 1 раз... Я умею в методологию и тестирование проводилось несколько раз по кругу, всё учтено, но значения при этом всегда одинаковые независимо от очерёдности. Диск был совершенно новый к тому же.

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

203. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 09:18 
>>что на уме у контроллера в любой момент времени и в каком реально состоянии те ячейки
> Если бы это было 1 раз... Я умею в методологию и тестирование
> проводилось несколько раз по кругу, всё учтено, но значения при этом
> всегда одинаковые независимо от очерёдности. Диск был совершенно новый к тому
> же.

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

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

205. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 24-Янв-20, 12:42 
Из чего это следует?
Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

200. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 24-Янв-20, 00:30 
> Он же на SSD ставил свои странные опыты. Это ненаучно. Надо было
> проводить тесты на предсказуемых и понятных HDD с хорошо известными характеристиками,

У SSD и HDD довольно разные характеристики - и таки знание о перфомансе на HDD не сильно поможет в оценке работы на SSD. SSD можно более менее научно тестить. Но канительно и можно облажаться.

Например:
1: trim всей поверхности
2: mkfs
3: бенчи
4: goto 1 (c другой ФС/конфигурацией)

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

202. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 09:15 
>> Он же на SSD ставил свои странные опыты. Это ненаучно. Надо было
>> проводить тесты на предсказуемых и понятных HDD с хорошо известными характеристиками,
> У SSD и HDD довольно разные характеристики - и таки знание о
> перфомансе на HDD не сильно поможет в оценке работы на SSD.

Спасибо, КО, просветил. Но речь была об оценке функционирования файловых систем, а не аппаратуры.


> SSD можно более менее научно тестить. Но канительно и можно облажаться.

SSD _нельзя_ научно тестировать (что такое «тестить», анон? Что-то связанное и тестикулами?), поскольку проприетарные контроллеры SSD и их фирмвари — терра инкогнита. Ты никогда даже в общем приближении не знаешь, как именно оно работает с ячейками и что конкретно делает. Ты даже не знаешь, сколько на самом деле ячеек внутри. Твой максимум — верить рекламе производителя. Даже что делает trim — ты тоже не знаешь. ;) Да и не имеет оно отношения к файловым системам.

А у хардов есть несколько измеримых свойств, от которых можно отталкиваться при сравнении (например, скорость вращения шпинделя и количество блинов), и кое-какие стандартизированные программные интерфейсы к потрохам (S.M.A.R.T.). Ничего такого для SSD нет: что написано в рекламном буклете, тому верить на слово.

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

220. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 24-Янв-20, 15:35 
> Но речь была об оценке функционирования файловых систем, а не аппаратуры.

Если кто еще не понял: на SSD и HDD соотношения разные! Как раз по линии железа. То что хорошо для HDD не обязательно хорошо для SSD, и наоборот. Поэтому то что ФС хорошо работает на HDD - ничего не говорит о том что она на SSD будет хорошо работать. Ну вот например, SSD бывают *ОЧЕНЬ* быстрыми. Настолько, что все может упереться в работу с метаданными по части ... проца. На HDD до этого момента добраться довольно сложно, разве что на многодисковой хранилке какой, в большинстве конфиг оно во что-нибудь другое быстрее упрется(скорость записи или seek-ов).

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

В общем, тесты на HDD ничего не говорят о работе ФС на SSD. Это 2 совершенно разных случая, где лохи и победители могут перетасоваться местами как делать нефиг.

> SSD _нельзя_ научно тестировать

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

> (что такое «тестить», анон? Что-то связанное и тестикулами?),

Бедный дедушка, походу у него проблемы.

> поскольку проприетарные контроллеры SSD и их фирмвари — терра инкогнита.

Поэтому давайте не будем ее изучать? Лол!

> Ты никогда даже в общем приближении не знаешь, как именно оно
> работает с ячейками и что конкретно делает.

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

> Ты даже не знаешь, сколько на самом деле ячеек внутри.

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

Часть блинов занята "блинварью", сектора которой накопитель стандартными командами вообще не отдаст. И есть резервные сектора. И что в каждом секторе на самом деле не 512 или 4096 байтов все наверное тоже уже догадались - там еще область ECC есть. Которую наружу никогда не отгружают. И прочие сервометки и т.п. чтобы вообще сектора искать.

Немного даже наверх вывешено. Как насчет HPA и DCO? Я даже встречал пару особо ушлых BIOS, тихо откусывающих себе кусочек от винча этими чудесами для складирования какого-то блоба (бэкапа биоса, чтоли). Заметить это не так то просто, кстати.

В общем, примерно как в SSD - у тех даже попроще местами.

> Твой максимум — верить рекламе производителя.

Ну так и у HDD как-то так же. На внутренних треках он будет раза в три медленнее чем на внешних, так что результат бенча тоже сильно зависит что куда попало.

> Даже что делает trim — ты тоже не знаешь. ;) Да и не
> имеет оно отношения к файловым системам.

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

> программные интерфейсы к потрохам (S.M.A.R.T.). Ничего такого для SSD нет: что
> написано в рекламном буклете, тому верить на слово.

У SSD тоже есть SMART, внезапно. И тоже есть измеримые свойства. Ну например скорость записи на pre-erased накопитель штука относительно стабильная и предсказуемая. Поэтому и предлагается trim по всей площади сделать, чтобы поставить все ФС в равные стартовые условия.

Иначе будет не честно когда один на pre-erased поверхности заскипал стирание, а второй туповэйтил. Второй ФС в результате подсунули более плохие стартовые условия чем первой.

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

130. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анон123 (?), 22-Янв-20, 00:56 
++++++
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

28. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 11:05 
>"silent corruptions"

Там чёт на ссд проблемы были если я верно помню, железоспецифичные баги. То ли дело xfs, зануляющая файлы, да? Ext4 у меня рассыпалась только по времена ext4dev, потом появились барьеры и она стала совершенно беспроблемной.

>fat тоже немножко отличается от msdos v1.0

Не особо. Потому что fat32 осталась в 90х и extfat это fat32.

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

34. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Zenitur (ok), 21-Янв-20, 11:25 
> fat32 осталась в 90х

В 2000-2005, флешки форматировали в FAT16, а 2005-2015 - в FAT32. Да и сейчас наверное тоже.

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

42. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –2 +/
Сообщение от пох. (?), 21-Янв-20, 11:58 
> В 2000-2005, флешки форматировали в FAT16

потому что в 2005м еще казалось весьма неплохой идеей выковырять из mp3 плейера _дисковый_ накопитель в CF формфакторе - и получить 4G по цене флэшки в 250мег. И тогда это было - очень много.
А в дорогущих цифрозеркалках внутре, помимо неонки, был ms-dos 3.какой-то - прямо с коммандцом и всей фигней. И у которого тогда еще не было китайских драйверов для 32.

А в "2k20" дешевые флэшечки стали по 250 гигабайт. И они - factory formatted в exfat, поскольку у fat32 с такими объемами некоторые проблемы. А сама fs появилась в 2006м - причем в системе, как раз ориентированной на portable применение - winCE (в XP ее портировали уже постфактум - надо ж было как-то читать флэшку из pda). То есть кто-то в MS тогда умел смотреть на десяток лет вперед.

Жаль что в 6ешплатных операционных системах таких людей уже в 2006м не оставалось. :-(

> Да и сейчас наверное тоже.

сейчас уже начинаются мелкие трудности с покупкой SDHC. У меня, к сожалению, как раз прорва устаревшей аппаратуры, не умеющей XC, даже если их переформатировать в fat32.
(не говоря уже о том, что там нафиг не нужны сотни гигабайт)

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

56. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –5 +/
Сообщение от Ыр2.0 (?), 21-Янв-20, 13:02 
О, робот, кто тебя написал? Я пытался анализировать твоё сообщение и пришёл к выводу, что ты - робот, который конструирует грамматически правильные предложения, но, к сожалению, не имеющие смысла.
Ответить | Правка | Наверх | Cообщить модератору

57. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –3 +/
Сообщение от пох. (?), 21-Янв-20, 13:10 
> О, робот, кто тебя написал?

боюсь, робот, ты обознался.

> но, к сожалению, не имеющие смысла.

для тех у кого нет мозга для понимания написанного - к сожалению, да.

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

54. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от пох. (?), 21-Янв-20, 12:48 
и нет, exfat ни разу не fat32.

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

62. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 13:22 
> и нет, exfat ни разу не fat32.

Спорное заявление, fat32 была ещё в 95 венде и exfat это изменённые поля и немного костылей и подпорок. На флешках не так заметно, но сама её суть довольно дефективна и она совершенно не изменилась.

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

67. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 13:37 
> Спорное заявление, fat32 была ещё в 95 венде и exfat это изменённые

ваша ext2 написана в 92м. По мотивам systemV fs, придуманной в каком-нибудь 76м.

Все что с тех пор добавили - это "измененные поля и немного костылей и подпорок".
На быстрых дисках не особенно заметна, но сама суть, ориентированная на очень медленные, очень ненадежные и очень малоемкие носители (поэтому и размазывали метаданные с inodes ровным слоем по всему диску) - ничуть не изменилась.
Более того, все еще можно создать fs, читающуюся драйвером ext2 (в некоторых случаях - просто поудалять новые фичи с уже существующей).

У exfat с fat32 общего - только сама концепция fat. Форматы - разные. Более того, в exfat fat не является единственным местом где может храниться информация о блоках файла. Структуры данных на диске - разные совершенно. Но религиозным фанатикам разница все равно не видна.

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

72. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 13:49 
Может хватит сравнивать несравнимое? Лучше сравнивать ext4 с ntfs (образца так эдак после 2010 года, потому что раньше были проблемки — у ntfs). Я вот не помню, исправили или нет у fat проблему с чтением файлов, они читались в порядке записи и никак иначе. Ничего кардинально нового я там не вижу. Да, лучше журналируемых подходит для флеш памяти (не ссд), но и только. Ext4 же всё это время претерпевала значительные изменения.
Ответить | Правка | Наверх | Cообщить модератору

86. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 15:17 
сравнивайте.
Только вот в моей практике - "раньше были проблемки" у ext4 - вплоть вот до полной неработоспособности. А с ntfs у меня на десятках систем - почему-то не было ни одной проблемы, включая, на удивление, и линуксы - что, интересно, я делал не так?

> Ничего кардинально нового я там не вижу.

потому что не хотите.

> Да, лучше журналируемых подходит для флеш памяти

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

> Ext4 же всё это время претерпевала значительные изменения.

"ничего кардинально нового я там не вижу". Кстати, в каком там году ntfs научилась хранить мелочь напрямую в mft? (это к вашему inlining)

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

87. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 15:26 
Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если включить какое-нибудь сжатие) не перестают удивлять и сегодня.

>с бесконечным дерганьем головами к журналу

Там совершенно другие головы, например. К тому же он кешируется в памяти?

>у ext4 - вплоть вот до полной неработоспособности

Можно подробности? Желательно после 2007 или когда там барьеры подвезли.

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

95. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (95), 21-Янв-20, 16:06 
> Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если включить какое-нибудь сжатие) не перестают удивлять и сегодня.

А меня в 2020-ом поражает нехватка inode-ов в ext4. Форматируешь какой-нибудь раздел на 512 мегов для хранения многих мелких файлов с дефолтными настройками, и огребаешь кучу геморроя при использовании. И такие проблемы только у ext-а. У reiser4, xfs, jfs таких проблем нет.

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

97. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 21-Янв-20, 16:13 
Самые маленькие разделы у меня 4 терабайта. Но и когда по 1 терабайту были нехватки инод ни разу не возникло. А на 0.2тб и данных столько не было. Это просто умолчания, на маленьком разделе хочется больше пространства под данные и меньше терять под метаинформацию. Если знаешь заранее. что понадобится много, их можно попросить.

>2020
>512 мегов

отличная шутка, лет на 30 опоздала.

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

109. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 17:58 
> отличная шутка, лет на 30 опоздала.

на 20. В начале 2000х я проблемы с нехваткой inodes еще помню.
Но тогда не было никакой ext4. А когда появилась хоть как-то живая ext4 - "разделы в 512 мегабайт" бывали только в каком-нибудь /boot - ему inodes хватило, он не жаловался. А 512 мегабайт - иногда не хватало.

(todo: открутить и выкинуть из жабиксового темплейта ненужные проверки inodes вместе с историей и триггерами, они  никогда в жизни не сработают, и ломаются на fs, ничего не слышавших ни о каких рариретах 76го года.)

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

98. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 17:26 
> Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если
> включить какое-нибудь сжатие) не перестают удивлять и сегодня.

ну вот я не наблюдаю какой-то катастрофической деградации на ntfs'ных дисках _десятилетнего_ возраста. Они, разумеется, не забиваются и не забивались под завязку, и да, сжатие я всегда считал дурным выбором (и тем почти спасся от очень малоприятных проблем в zfs - если бы не прозевал что обо мне позаботились и включили его в еще одном месте ;-) - возможно, если бы оно активно использовалось, что-то бы изменилось. (в конце-концов, ms зачем-то сует в планировщик дефрагментатор, хотя у юзеров и немного шансов что он успеет сработать)

К тому же в многозадачной системе не нужно отсутствие фрагментации, ей нужен правильный планировщик io. (а у нас - 12309)

> Там совершенно другие головы, например. К тому же он кешируется в памяти?

так журнал же ж! его нельзя кэшировать, в том и суть.

> Можно подробности? Желательно после 2007 или когда там барьеры подвезли.

когда подвезли, мы уже на xfs перешли (уже не вспомню что именно в той среде мешало нам выключить журнал, а с включенным оно тормозило в самые неподходящие моменты. К тому же про гугля мы тогда не знали, он умел хранить свои секретики). Так что полных крэшей, когда уже проще плюнуть на пропавшие данные и не пытаться ничего выковыривать, наверное, после ~2008го лично я уже не видел, только "massive filesystem corruptions" и "minor silent corruptions", угу. Но эти хотя бы исправлял fsck и md5sum позволял потом выявить испорченное.

Что на фоне моих прошлых пяти лет, прожитых в основном с ufs, все равно выглядело, мягко говоря, бледненько.
То есть вот привычка хранить рядом с крупными файлами их md5 - она у меня примерно тех времен, когда "барьеры подвезли", а данные не портить почему-то все равно не получалось. В начале 2000х у меня такой не было, и как-то обходилось. Может потому что диски были сильно меньше.

Но обратите внимание - ntfs живет с еще более ранних времен, и по сей день.

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

108. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анонимун (?), 21-Янв-20, 17:58 
>сжатие я всегда считал дурным выбором

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

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

111. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 18:00 
ну типа если места дефицит - надо найти диск побольше, а этот положить на полку. Потому что диски это только деньги, а время, которое даром тратится на ненужные сжатия-разжатия - мое. Не говоря уже о возможных глюках (кстати, может по этой причине у меня ntfs-то и не портилась? Там, правда, есть пара мест, где винда включает ненунжосжатие без спросу.)

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

119. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анонимун (?), 21-Янв-20, 18:21 
>диск побольше

А если раздел?

>надо найти диск побольше

Ну ты же деньги дашь?

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

126. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 22:19 
>>диск побольше
> А если раздел?

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

Ну или пользоваться zfs, которой никакие разделы не уперлись. (ну или lvm, кто совсем ту...э...бесстрашный)

>>надо найти диск побольше
> Ну ты же деньги дашь?

себе-то? Конечно дам, новый диск, а не губная помада, чай.
Речь-то шла о том, как я для себя поступаю. У меня, напомню, "разделов" в 512 мегабайт нет окромя /boot, да и тот на legacy системах, уже лет двадцать. А васяны пускай страдают "от ужастной нехватки inodes", сами себе разложив грабли, сами их преодолевают.

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

229. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (-), 24-Янв-20, 21:30 
> А с чего так, если места дефицит? Оно там правда очень небольшое,
> в угоду производительности.

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

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

110. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анонимун (?), 21-Янв-20, 18:00 
>ms зачем-то сует в планировщик дефрагментатор

Она много чего туда сует. Замучаешься выгребать. Что интересно, в XP еще не было такого безобразия. Додеградировали до 10.

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

121. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним84701 (ok), 21-Янв-20, 19:29 

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

Э-э-э ... и напуркуа тогда вообще журнал сдался? Чтобы лучше данные портить? o_O


https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
>  * writeback mode
> In data=writeback mode, ext4 does not journal data at all.  
>  A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash.

...
>writeback:  Data ordering is not preserved, data may be written
>            into the main file system after its metadata has been
>            committed to the journal.

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

123. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 21-Янв-20, 20:06 
Я использую data=writeback. Данные не журналируются, но метаданные вполне себе да. И барьеры есть. Журнал нужен, чтобы не повредить метаданные. Потому что если они повредятся, фс резко поплохеет и потерей пары временных файлов из кэша браузера (уже удалённых) не отделаешься. Журнал периодически синхронизируется с памятью, но происходит это периодически, а не прямо сейчас. Lazytime позволяет значительно минимизировать записи на диск, но время изменения файлов в случае внезапного отключения может сильно пострадать.
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

162. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 22-Янв-20, 20:33 
> Я использую data=writeback. Данные не журналируются, но метаданные вполне себе да. И
> барьеры есть. Журнал нужен, чтобы не повредить метаданные. Потому что если

вообще-то такой журнал придуман совершенно для другого - чтобы сэкономить время на fsck.
Когда этот коран писали - самой большой проблемой наследников system7 было неприемлемо выросшее время проверки диска после перезагрузки ресетом, когда емкость дисков резко скакнула с десятков до сотен гигабайт.

В результате кто-то запилил "background fsck" (чур меня, чур!) а кто-то - вот такую хрень, журнал метаданных.

> они повредятся, фс резко поплохеет и потерей пары временных файлов из

журнал на не cow-fs в принципе не гарантирует что они "не повредятся". А тем более журнал в режиме записи данных вперемешку с метаданными.

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

Если журнала нет - еще можно пытаться что-то ловить в lost+found (в надежде что повредили мы содержимое directory, а не inode с данными). Если журнал есть - ловить нечего, поскольку он вернет тебе систему в "консистентное" состояние, пооверрайтив неконисистентные метаданные - _устаревшими_. Поскольку у нас тут не коровье пастбище и файлы были перезаписаны по месту (а журнал об этом узнать не успел) - у тебя теперь вместо их содержимого веселенькая вермишель.

"зато fsck ненужен!" и "смотрите как быстро загрузились после крэша!"

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


# ls -la /lost+found/
total 608
drwx------  2 root root   16384 Sep  5  2015 .
drwxr-xr-x 22 root root    4096 Jan  8 08:08 ..
-rw-------  1 user users 190946 Dec 26  2015 #3146740
-rw-r--r--  1 user users  33156 Sep 22  2015 #3162003
-rw-------  1 user users 318722 Jan  6  2016 #3165803
-rw-r--r--  1 user users  52401 Apr 12  2018 #3286995

система не выключается практически никогда, и периодически виснет (d2700, да, традиционная проблема с мостом) С 2011го года, как видим, ничегошеньки фатального с нежурналируемой fs не случилось.

в /tmp/lost+found мусор удаляется, но там его не то чтобы на порядок больше - noatime+barrier=0 очень здорово уменьшают шансы повиснуть именно в момент записи метаданных.

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

163. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 22-Янв-20, 20:50 
Устаревшими = предыдущими консистентными? Так это же прекрасно, битые файлы нам не грозят. Синхронизация разве проводится не достаточно часто, что забить на несколько секунд сверхважных изменений в данных? Заодно передаю привет https://www.opennet.ru/opennews/art.shtml?num=50148
Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

170. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 23-Янв-20, 15:08 
предыдущими консистентными - метаданными. То есть соответствием inode indexes и тому что в них самих написано. fsck счастлив.

А предыдущие консистентные _данные_ внутри этой inode - ниоткуда не возьмутся, они уже давно перезаписаны вообще другой информацией, а то что там должно быть - лежит где-то еще, но на это место не ссылаются метаданные, мы их "откатили" (поэтому ты не сможешь восстановить его из lost+found). То есть это именно битый файл.
Если "забить на несколько последних испорченных файлов" - то да, но, к сожалению, продолжением является - "а теперь угадай, какие именно - испорчены". Это не какой-то баг ext2+, а врожденная фича всех не-cow fs (а cow приносит с собой свои, тоже не всегда прекрасные).

То есть ситуация от ситуации вообще без журнала отличается только отсутствием необходимости ждать fsck - ценой потери производительности на "достаточно частое" переписывание из пустого в порожнее (оно синхронное, что радости не добавит)

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

> Заодно передаю привет https://www.opennet.ru/opennews/art.shtml?num=50148

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

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

176. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 23-Янв-20, 20:08 
Хех, мы вроде уже выяснили, что "в 100 раз" — это ради красного словца? Я тогдапредположил, что это кеширование и без журнала оно менее эффективно (кэши фс я сбрасывал через троечку).

Что до остального, разве барьеры не решают именно эту проблему? Я не помню, чтобы хоть раз у меня появились битые данные на ext4. На ntfs, впрочем, тоже — у неё проблемы с повреждением структур, но не данных.

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

164. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 22-Янв-20, 21:04 
>файлы либо нулевой длины, либо с прежним содержимым, либо исчезли

Это, кстати к xfs, на ext4 такое маловероятно. Зачем проецировать опыт работы с дефективными фс на ext4?

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

106. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анонимун (?), 21-Янв-20, 17:55 
>NTFS

А там торрент клиенты все также жутко фрагментируют файлы, кроме малварного utorrent?

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

112. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 18:03 
пользуюсь на винде малварным муторрент, поэтому не знаю ;-)

P.S. что, реально настолько п-ц? ВСЕ вот прямо - все другие поделки не умеют prealloc? Уж что-что, а размер файлов в торренте всегда известен заранее. Создавать их в винде нативной программой без preallocation - это просто гейклуб какой-то, простите за выражение.

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

118. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Анонимун (?), 21-Янв-20, 18:20 
>реально настолько п-ц?

С разряженными файлами просто дичь. А preallocation очень медленный. Не знаю уж что накостыляли в utorrent, чтобы это обойти.

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

186. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 21:59 
> пользуюсь на винде малварным муторрент, поэтому не знаю ;-)
> P.S. что, реально настолько п-ц? ВСЕ вот прямо - все другие поделки
> не умеют prealloc? Уж что-что, а размер файлов в торренте всегда
> известен заранее. Создавать их в винде нативной программой без preallocation -
> это просто гейклуб какой-то, простите за выражение.

Они умеют prealloc, но как-то странно. Упомянутый qBittorrent, например, при _снятой_ в настройках галке о сабже и при выборочном скачивании содержимого торрента всё равно пишет на диск всякий мусор предположительно такого размера, как у файла, который ты не хочешь скачивать и заказал не скачивать.

Я, пожалуй, постепенно плюну на этот хвалёный опенсорс и тоже перейду на мюторрент, хотя он не столь удобен, как qBittorrent.

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

184. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 21:56 
>>NTFS
> А там торрент клиенты все также жутко фрагментируют файлы, кроме малварного utorrent?

За все не скажу, а qBittorrent мне однажды сделал веселье. Деталей уже не помню, хотя писал об этом случае в комментариях, кажется. Было что-то, ЕМНИП, с неправильным определением размера ФС (один раздел на весь диск). Пришлось из Live-среды отрезать от ФС около гигабайта и выбросить во тьму внешнюю, дабы сохранить остальной терабайт живым. Получилось, ЧСХ. Зря не задокументировал подробностей, вот прямо жалею.

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

234. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Vanych (?), 17-Фев-20, 16:06 
> сама суть, ориентированная на очень медленные, очень ненадежные и очень малоемкие носители (поэтому и размазывали метаданные с inodes ровным слоем по всему диску)

- Вот тут Вы "слегка" :-) подзабыли. Ext2, не смотря на свой более старший возраст была ЗНАЧИТЕЛЬНО лучше по всем параметрам современной ему FAT (дешевая система для Кухарок - дешевая FS, от куда в MS было взяться хорошим (дорогим) разработчикам? Это потом, разбогатев, MS смог купить крутых UNIX-оедов для разработки технологии "NT").
Inodes, размазанные по диску ввиду их цепочности как раз значительно (в дополнение к кешированию) ускоряют работу механического диска из-за близости к данным (поступательное движения головки и ожидания на дорожке подхода нужного сектора), ну и повышается надежность. Мне, в былую тяжелую жизнь очень часто перепадали большие и достаточно новые диски с протертыми начальными цилиндрами, куда Вындовс складывал обе таблицы, достаточно было их отрезать.

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

134. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 22-Янв-20, 03:06 
> fat тоже немножко отличается от msdos v1.0, но вы этого предпочли не видеть

И где там экстенты или индексированные диры? :) А без всего этого он тормозной и на сколь-нибудь разлапистой иерархии встает колом.

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

78. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +2 +/
Сообщение от iZENemail (ok), 21-Янв-20, 14:40 
> На сегодня на роль универсальной фс общего назначения у ext4 нет конкурентов, поскольку она лучше во всём одновременно.

Ну это бред же. "Лучше" в чём? По-мне, так XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования.

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

80. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (10), 21-Янв-20, 14:48 
>XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования

Они уже перестали необратимо деградировать? В ext4 подпёрли костылями и вполне нормально. Единственный "недостаток" у ext4 — это ограниченное число инод, что на практике не так страшно. Лучше по всем параметрам использования.

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

82. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +2 +/
Сообщение от пох. (?), 21-Янв-20, 15:01 
>>XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования
> Они уже перестали необратимо деградировать?

redhat уверяет, что да (точнее что нет, нам и раньше показалось, но сейчас - точно перестали)
В ufs - это вам кто-то вредную сказку на ночь опять рассказал, ничего там не "деградирует".

> В ext4 подпёрли костылями и вполне нормально.

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

> практике не так страшно. Лучше по всем параметрам использования.

главное - верить?!

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

83. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (10), 21-Янв-20, 15:07 
> главное - верить?!

Главное — опыт. Вот о ntfs я ничего хорошего сказать не могу, о xfs тоже. Да и о ext3, в принципе. При этом ext4 за годы использования повсеместно зарекомендовала себя исключительно положительно.

Про ufs2 я ничего не знаю, но опыт общения с ufs1 был довольно удручающим.

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

88. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +3 +/
Сообщение от пох. (?), 21-Янв-20, 15:28 
> Главное — опыт.

опыт без попыток анализа - так и остается anecdotal evidence.

Я вот ничего плохого об ntfs сказать не могу - у меня ни одна сама по себе не сдохла, с 1994го года. Только вместе с полным необратимым разрушением носителей. И ни одного файла "просто так" не потеряла - только при повреждениях физической структуры.
Об ext2, в отличие от ext3 и 4 - тоже не могу.
C xfs были приключения, в виде регулярных крэшей - но это было до попадания ее в лапы redhat, и, полагаю, сейчас эти проблемы крайне маловероятны. Я ее не люблю и стараюсь не пользоваться, но отдаю себе отчет в том, что это - иррациональное желание, не имеющее адекватных технических оснований.

Опыт с ufs2 и ufs1 лично у меня - "ни единого разрыва" (кстати, откуда он у вас "удручающий" и с чем вы ее сравниваете - c ntfs3 ? ufs2 - это примерно все тот же 2005й) , правда, я не использовал экстремальные варианты и избегал очевидно опасных.

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

94. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 21-Янв-20, 15:55 
Ооо, про ntfs я могу рассказать много хорошего, поскольку я спокойно пользуюсь и вендой. Нтфс из икспишечки (3.1) рассыпалась просто по расписанию и по любой причине (и без), нтфс из 7 рассыпалась уже реже, но подозрительно часто. Особенно заметно, когда место на системном диске кончалось. Приходилось устанавливать начисто, потому что восстановиться с лайвсиди она не могла. Да и 10 как выяснилось недалеко ушла. Неудаляемые каталоги ни с того ни с сего, неудаляемые файлы, битые файлы, разваливание на ошмётки от chkdsk (тут или исправит, или рассыпется в пыль)… Сколько всего было, и это даже без сжатия с шифрованием (с ними — сплошной кошмар). И да, диски были в полном порядке.

Про использование ntfs через ntfs-3g и говорить нечего, у меня всего за пару лет использования практически в read-only (года так с 2018), она приобрела невосстановимое состояние и часть файлов случайным образом может отказаться удаляться. Нужно прогонять chkdsk и это плохо кончится, поэтому пользуется пока так. Фрагментация просто космическая (особенно на мелких файлах вроде профилей браузеров, тот же стим умеет правильно попросить ос и файлы не фрагментируются так).

Поэтому заявления на тему УМВР выглядят в высшей степени нездорово для меня.

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

100. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от пох. (?), 21-Янв-20, 17:37 
> Нтфс из икспишечки (3.1) рассыпалась просто по расписанию и по любой причине (и без)

Вот что я делал не так, что у меня не рассыпалась? Диски с ntfs из под xpшечки вон, лежат себе на полке по сей день - там обработанные и полуобработанные фотки, которые никогда не удалялись, и когда место кончилось - были убраны в архив с дисками.
Отдельно интересно что я делал не так на полу-production серверах, с 24x7 и прочими прибабахами, те, конечно, столько не жили, но вполне продолжали работать, когда я уходил из тех контор.

> Особенно заметно, когда место на системном диске кончалось.

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

Отдельный вопрос - как за два года можно убить ntfs используемую в режиме "почти readonly"? Я, конечно, понимаю, что у меня-то немодный-немодный мамонтов кал какого-нибудь 2011го года (а ntfs'ным дискам, соответственно, поболее), и, возможно, ntfs3g с тех пор стали писать не руками а другим местом?
"BUT HOW?!" учитывая что она просто работала - что и зачем там с тех пор ТАК наулучшали?

Что именно мне теперь не стоит апгрейдить - fuse, саму ntfs3g, ядро, или все вместе?

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

122. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (122), 21-Янв-20, 19:38 
> Вот что я делал не так, что у меня не рассыпалась?

Наверное не тащил с помойки навозную комплектуху и на неё не пытался ставить вин?

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

125. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 21-Янв-20, 20:37 
ну вот те диски, на которых по сей день, наверное, живет XP, поставленная в 2003м году, если подключить в правильные порты (кажется, все железо там еще правильных с ее точки зрения id, хотя тумбочка давно переделана под линукс а потом просто забыта) - они считай с помойки. Вынуты мной из сервера, обеспечившего мне ночную поездочку к хостеру (в той конторе было принято менять диски в сервере ровно один раз - случайный сбой, не случайный - нахрен с пляжа, в десктопы или в дискеты, простой обходится дороже и ночью надо спать). Один, похоже, и впрямь был слегка сбойный, второй вроде нет - но живы оба. Были, два года назад, когда подключал что-то оттуда прочитать.
Использовались, что характерно, первые пару лет для торрентов ;-) Но да, mTorrent, он умеет в prealloc ;-) Лежали на подоконнике рядом с платой, корпуса лишнего не нашлось ;-)

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

То есть совсем помойного железа вроде как и не держал никогда, но никаких чудес и золоченных оплеток кабелей. Скорее - аккуратная эксплуатация и расследование странностей типа "не загрузилось", "стало виснуть", или "странные звуки из корпуса" (обычно все три - повод выбросить блок питания со вздувшимися конденсаторами. Кстати, самым дрянным оказался дорогущий thermaltake)
Ну и chkdsk в любом случае, вызывающем подозрения целостности.

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

127. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от анонимуслинус (?), 21-Янв-20, 22:37 
кондеры перепаял и в путь. у меня перепаяная geforse gt 1800  до сих пор пашет. точнее рабочая лежит. но да старое оборудование как то более живучее . даж системник на селероне 1800(опять 1800))) работает. там правда жесткий тольк 40 гигов. но на нем у меня линей перепробовано куча. правда с кедами 4 решил не мучать его. до сих пор на нем стоит мандрива 2007. а ext  что 4, что 5 очень даже приличная фс. вспомни лучше про крики про ext2.)))
Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

137. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (-), 22-Янв-20, 03:12 
> но да старое оборудование как то более живучее

Только холодное и маложручее. И к старости это никак не относится. Только к прожорливости и температурным режимам. А так - эээ вы вообще видели например современную мамку с полимерными конденсаторами и чтоб это сдохло? Они за обозримое время вообще не мрут вроде.

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

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

150. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от пох. (?), 22-Янв-20, 12:36 
> кондеры перепаял и в путь

ты будешь смеяться, но на дорогущем thermaltake с отсоединяемыми кабелечками - для "перепаять кондеры" оказалось нужно выпаять ВСЕ силовые ключи, и оторвать их разлапистые радиаторы, именно в этой последовательности, по другому - вообще никак. Неремонтопригодность = 100% (и, конечно же, те самые помоешные китайские электролиты рупь пучок)

Диск, кстати, после работы с ним начал как-то подозрительно похрюкивать. Но пока ntfs цела.

> вспомни лучше про крики про ext2.

не считая печальной истории с лимитом 2G - вот вообще не припомню ни одной проблемы с ext2. То есть там тоже были всякие "massive corruptions", при том что в те времена иногда было просто необходимо ставить именно самое распоследнее ведро, а не надеяться на штабильный дистрибутив, но меня они вполне счастливо обошли стороной. А потом линуксы пошли строем на помойку по несвязанным с fs причинам.

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

182. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (182), 23-Янв-20, 21:47 
> "перепаять кондеры" оказалось нужно выпаять ВСЕ силовые ключи, и оторвать их
> разлапистые радиаторы, именно в этой последовательности, по другому - вообще никак.

1) Термалтейк средняя фирма. То что они дорогущие не мешает ставить паршивенькие конденсаторы фирм "почетного" списка ROM.BY. Вероятно ОЕМают у кого-то среднего и лэйбу клеят. Не знаю у кого, подворачивавшиеся мне слишком просто чинились.
2) Это что-то не повезло. Я несколько таких халявно поднял в режиме прогулки: там дежурка дохла, 2 кондера в легкодоступном месте.
3) В одном забавном экспонате ... заменил мелкий кондер без отпайки ключей. Тоже дежурка, но - питание контроллера. Снимать радиаторы было лень и я придумал как замену инстальнуть в узкое место без этого :)

> Неремонтопригодность = 100% (и, конечно же, те самые помоешные китайские электролиты рупь пучок)

Термалтейк так умеет. Хотя лично мне дохлые кондеры в основном питании у них не попались, только в дежурке. В таком виде - халява, сэр. Для юзерей они 100% трупы в таком виде :)

Ну и как-то вышло что в питальники ставят обычное барахло. Счастье коснулось питальников процов, в топовых мамках. Там токи 100А и более - тяпо-ляпо вскипает в момент и мамку несут по гарантии. Пришлось что-то придумать. И вот такие дохлые полимеры я вообще не видел.

> Диск, кстати, после работы с ним начал как-то подозрительно похрюкивать. Но пока ntfs цела.

Ну так см. смарт, ремапнутые сектора и read errors rate или что там. Иногда в результате глюков питания винчи делают "софт бэды". Видимо криво считают ECC при глюках - винч ловит "soft" read error - retry - read error - retry - упс, ну нищмагла я, UNC. При перезаписи сектора он однако приходит в адекват и казалось бы жуткий смарт вдруг расчищается и винч почти как новый.

А вот кстати DUP в btrfs от подобных приколов - очень даже, там теорвер в сторону юзера малость вертают :P

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

189. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 23-Янв-20, 22:07 
Чувак, у тебя наверняка что-то с питанием. В смысле — в розетке и/или в БП.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

197. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 23-Янв-20, 22:53 
> Чувак, у тебя наверняка что-то с питанием. В смысле — в розетке и/или
> в БП.

Да, я уже поменял место жительства, купил упс, и всё остальное. Емнип наиболее частые проблемы с нтфс были после бсодов всё же. Видел пару раз бсоды на 10, но стало намного лучше чем было прежде. А ещё 10 не приходится с кнопки перезагружать, даже если она зависает можно перезапустить видеодрайвер и она скорее всего раздуплится. Линукс же ребутался с кнопки из-за того что память кончалась, паники дело достаточно исключительное и происходят в основном из-за багов железа (под вендой это же железо как-то может работать без багов надо понимать).

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

204. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 09:22 
>> Чувак, у тебя наверняка что-то с питанием. В смысле — в розетке и/или
>> в БП.
> Да, я уже поменял место жительства, купил упс, и всё остальное. Емнип
> наиболее частые проблемы с нтфс были после бсодов всё же. Видел
> пару раз бсоды на 10, но стало намного лучше чем было
> прежде. А ещё 10 не приходится с кнопки перезагружать, даже если
> она зависает можно перезапустить видеодрайвер и она скорее всего раздуплится. Линукс
> же ребутался с кнопки из-за того что память кончалась, паники дело
> достаточно исключительное и происходят в основном из-за багов железа (под вендой
> это же железо как-то может работать без багов надо понимать).

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

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

206. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 24-Янв-20, 13:28 
>больше никто не пишет

Остальным пофиг. Промелькало там что-то на экране и ладно — всё равно не поймёшь, что там написано.

>Логика здравого смысла подсказывает

Это не логика, это желание найти простое объяснение. Жёсткие косяки в проектировании (которые разработчики даже где-то когда-то признали) фанатам индусского проприетарного кода кажутся менее вероятными. Видимо по причине когнитивных искажений.

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

207. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 13:30 
Не хочешь советов — проигнорируй и страдай дальше.
Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

212. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 24-Янв-20, 13:44 
> Не хочешь советов — проигнорируй и страдай дальше.

Я не страдаю. Наученный опытом, я учитываю теперь, что самая большая ошибка, которую можно совершить с дисками — это выбрать нтфс под хранилище. В 10 с ней всё _гораздо_ лучше, однако ntfs3g её разносит достаточно быстро, как выяснилось. И она всё ещё фрагментируется и тормозит (очень ощутимо). В связи с чем, любители 7 кажутся особо забавными.

К сожалению, для венды вариантов не много, но можно просто не хранить на ней ничего ценного. Она у меня даже в виртуалке запускаемой от случая к случаю рассыпалась (xp,7).

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

215. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 13:49 
>> Не хочешь советов — проигнорируй и страдай дальше.
> Я не страдаю. Наученный опытом, я учитываю теперь, что самая большая ошибка,
> которую можно совершить с дисками — это выбрать нтфс под хранилище.
> В 10 с ней всё _гораздо_ лучше, однако ntfs3g её разносит
> достаточно быстро, как выяснилось. И она всё ещё фрагментируется и тормозит
> (очень ощутимо). В связи с чем, любители 7 кажутся особо забавными.
> К сожалению, для венды вариантов не много, но можно просто не хранить
> на ней ничего ценного. Она у меня даже в виртуалке запускаемой
> от случая к случаю рассыпалась (xp,7).

Всё-таки поинтересуюсь: что ты с ней делаешь, что она у тебя рассыпается? Миллиарды хардов с ней как-то живут и даже всякие вредные торренты крутят.

Против фрагментации микромелкие придумали запускать по расписанию (по ночам) дефрагментатор. Если машина работает круглосуточно, он решает эту проблему.

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

218. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 24-Янв-20, 14:01 
Ничего особенного, всё как у всех. Создаю, удаляю файлы. Много файлов. Архивы, распаковка-упаковка. Файлы-файлы-файлы. Торренты тоже бывали конечно, надо же скачивать линукс для виртуалки хотя бы. Главное, не запускать chkdsk, чтобы она там в тихую что-нибудь не исправила (венда периодически сама её запускает при загрузке, даже если ты не просил). Лучше всего не перезапускать, т.е. полгода и более аптайма (опять же, чтобы при загрузке не починила). Ну и дефрагментация очень сомнительное занятие, даже если есть время простоя, двигать все эти терабайты туда-сюда сомнительное развлечение (которое создаёт ощутимые вибрации и греет диски). По ночам пк должен быть либо выключен, либо заниматься полезной ресурсоёмкой работой.
Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

219. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 24-Янв-20, 14:06 
Кстати насчёт файлов, они таки бились. Фоточки бились целиком или частично, картиночки, видосики, архивы не проходили проверку… Даже на файлах, которые никто не трогал, кроме разве что дефрагментатора. Может, конечно, и не в нтфс дело, но смарт тесты были в порядке, а на ext4 такого не случалось.
Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

222. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (-), 24-Янв-20, 16:48 
> Миллиарды хардов с ней как-то живут и даже всякие вредные торренты крутят.

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

> Против фрагментации микромелкие придумали запускать по расписанию (по ночам) дефрагментатор.
> Если машина работает круглосуточно, он решает эту проблему.

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

Хранилки на винде и проч - блин, виндус сервер стоит конских денег и при том даже если бы он был бесплатным, он не имеет предложить вообще совсем ничего интересного, кроме дурного гимора с администрированием и вулнами.

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

226. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (226), 24-Янв-20, 19:31 
ntgs3g он с ней делает.
Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

227. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 19:41 
> ntgs3g он с ней делает.

Похоже на то.

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

113. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Анонимун (?), 21-Янв-20, 18:03 
>NTFS ни одного файла "просто так" не потеряла

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

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

144. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (-), 22-Янв-20, 03:32 
Еще интереснее бывает если флеху или sd сдернуть без размонтирования. У некоторых вообще таблицы трансляции после этого слетают. И файлы выглядят очень интересно. Примерно как если бы вы их перемешали в блендере.
Ответить | Правка | Наверх | Cообщить модератору

151. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от пох. (?), 22-Янв-20, 12:37 
ntfs проклятая виновата! И лично Блин Гейц дотянулся!

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

183. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (182), 23-Янв-20, 21:52 
> ntfs проклятая виновата! И лично Блин Гейц дотянулся!

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

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

192. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 23-Янв-20, 22:28 
По-моему начиная с 10 мс взял пример с кде и флэшечки теперь можно дёргать относительно спокойно, если прогресс бар дошёл до конца.
Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

208. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 13:31 
> По-моему начиная с 10 мс взял пример с кде и флэшечки теперь
> можно дёргать относительно спокойно, если прогресс бар дошёл до конца.

Настройки кэширования для сменных носителей (да и для хардов тоже) присутствуют в оффтопике ещё, наверное, с тех времён, когда про линукс никто не слышал.

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

214. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (10), 24-Янв-20, 13:47 
>> По-моему начиная с 10 мс взял пример с кде и флэшечки теперь
>> можно дёргать относительно спокойно, если прогресс бар дошёл до конца.
> Настройки кэширования для сменных носителей (да и для хардов тоже) присутствуют в
> оффтопике ещё, наверное, с тех времён, когда про линукс никто не
> слышал.

Как много пользователей туда заглядывало? К тому же настройки там по-моему для устройства задаются (или для буквы, не помню). Приемлемые дефолты для флэшечек появились только в 10.

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

216. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Anonymoustus (ok), 24-Янв-20, 13:56 
>>> По-моему начиная с 10 мс взял пример с кде и флэшечки теперь
>>> можно дёргать относительно спокойно, если прогресс бар дошёл до конца.
>> Настройки кэширования для сменных носителей (да и для хардов тоже) присутствуют в
>> оффтопике ещё, наверное, с тех времён, когда про линукс никто не
>> слышал.
> Как много пользователей туда заглядывало?

Это уже другой вопрос. :)


> К тому же настройки там по-моему для
> устройства задаются (или для буквы, не помню). Приемлемые дефолты для флэшечек
> появились только в 10.

В диспетчере устройств в свойствах накопителя — вкладка «Политика».

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

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

221. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +1 +/
Сообщение от Аноним (-), 24-Янв-20, 15:59 
> Она отключает кэширование.

...и превращает флешку в черепаху. Потому что совсем без кеширования да с убогим контроллером... мм...

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

132. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от iZENemail (ok), 22-Янв-20, 01:47 
>>XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования
> Они уже перестали необратимо деградировать?

Они переживают носители, на которых первоначально размещаются. Прикинь, dump/restore делают своё дело на уровне блоков ФС и бэкапят данные в tar на другое устройство. А впоследствии, когда носитель уходит в мир иной, данные ресторятся на новый в той же файловой структуре, какими были изначально. Ничего не напоминает?

> В ext4 подпёрли костылями и вполне нормально.
> Единственный "недостаток" у ext4 — это ограниченное число инод, что на
> практике не так страшно. Лучше по всем параметрам использования.

Только эта [Ext4] ФС не переживает своего физического носителя - время жизни ограничено. Поэтому что-то в ней оптимизировать на этот счёт нецелесообразно.

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

136. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (-), 22-Янв-20, 03:10 
Ух, я уж думал что изену пересадили мозг. Ан нет, опасения были напрасны, его адеквата хватило только на 2 дня.
Ответить | Правка | Наверх | Cообщить модератору

196. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (10), 23-Янв-20, 22:34 
Не понимаю, в чём смысл переносить битые файлы. Там хотя бы есть возможность узнать, что они битые? Но с этим у всех кроме разве что zfs с btrfs сложности. Переносить разделы (и сжимать их), либо тарить содержимое со всеми возможными атрибутами (и сжимать тарбол) так-то можно с любыми фс, если что.
Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

231. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (-), 25-Янв-20, 00:48 
> Не понимаю, в чём смысл переносить битые файлы.

Это iZEN. Он крут в откаблучивании странных действий, бессмысленно и беспощадно.

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

135. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от Аноним (-), 22-Янв-20, 03:08 
> XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования.

XFS офигенен когда с метаданными работает - тормозит он и правда в разы сильнее ext4. Да что там, даже он даже btrfs перетормаживает в этом аспекте. Хотя не умеет и 10% от его возможностей.

А ufs2 - чего в нем офигенного, кроме того что господа офигели такой античный дизайн в 2020 году таскать? :)

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

146. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  –1 +/
Сообщение от RudW0lfemail (?), 22-Янв-20, 06:14 
Поделитесь пожалуйста в чем перелесть работы с метаданными в XFS? Есть инструменты восстанавливающие ФС после краша?
Ответить | Правка | Наверх | Cообщить модератору

185. "Samsung предложил новый вариант драйвера exFAT для ядра Linu..."  +/
Сообщение от Аноним (182), 23-Янв-20, 21:56 
> Поделитесь пожалуйста в чем перелесть работы с метаданными в XFS?

Прелесть, к сожалению, в обратную сторону - он при активной работе с метаданными жестоко тормозит. Никогда не видели как файл стирается *минуту*? На XFS так бывает :)

> Есть инструменты восстанавливающие ФС после краша?

Тот реверанс был про фирменную скорость работы с метаданными, которая мне почему-то не очень нравится, по поводу чего я и избавился у себя от XFSов.

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

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

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




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

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