Компания Samsung предложила для включения в ядро Linux набор патчей с реализацией нового драйвера exFAT, основанного на актуальной кодовой базе "sdfat", развиваемой для прошивок Android-смартфонов Samsung. Если патчи будут приняты, то они войдут в состав ядра Linux 5.6, релиз которого ожидается через 2-3 месяца. По сравнению с ранее добавленным в ядро драйвером exFAT, новый драйвер обеспечивает прирост производительности примерно на 10%...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52222
> компания Microsoft опубликовала общедоступные спецификации и предоставила возможность безвозмездного использования патентов на exFAT в Linux, в экспериментальный раздел "staging" ("drivers/staging/") ядра 5.4 был добавлен драйвер exFAT, также разработанный в Samsung, но основанный на устаревшем коде (версия 1.2.9). Энтузиастами из Android-прошивок был портирован новый драйвер sdFAT (2.x), но компания Samsung самостоятельно решила заняться продвижением этого драйвера в основное ядро Linux. Кроме того, компанией Paragon Software был открыт альтернативный драйвер,Игра "сосчитай сколько уже драйверов для этой фигни", лучше бы для ZFS столько.
ZFS в Соляре - 1, в Линуксе со своей отдельной лицензией - 2, во FreeBSD - 3. Никого не забыл? Ориентируюсь чисто на те вариации, про которые тут новости видел. (Можно для смеху макось упомянуть, вроде с ZFS там опыты проводили, но как я понял - выкинули).
+ illumos
Во бзде вроде на ZoL перешли. Так что есть 2 варианта - с SPL и без.
> Во бзде вроде на ZoL перешли.Все еще нет. И судя по активности, вряд ли в обозримом будущем "перейдут"
https://github.com/zfsonfreebsd/ZoF/commits/projects/zfsbsd
> (Можно для смеху макось упомянуть, вроде с ZFS там опыты проводили, но как я понял
> - выкинули).zfs там была ровно такая же, как в линуксе - 3d party разработка, не имеющая никакого отношения к огрызкам. Периодически даже что-то от них прибегало в апстрим.
Никто ничего не выкидывал, но, насколько я видел - разработчики потихоньку разбежались, год линукса объявлять на десктопах, видимо.
Раньше каждый писал свой драйвер для fat. По причине относительной простоты, эта файловая система зачастую является одной из первых, поддерживаемых в новых операционных системах. А exfat, насколько я знаю, является всего лишь некоторой адаптацией той примитивной файловой системы под современные требования. Сравнивать с нормальными файловыми системами нет никакого смысла (я не утверждаю, что zfs нормальная).
Нормальные - это NTFS и EXT4
NTFS - нормальные... сударь... фи...
Относительно FAT - вполне себе.
А CDROM так очень даже ничего по сравнению с флопиком...
NTFS может сломаться только в том случае, если кто-то разобъёт HDD молотком.
А вот в линуксе так до сих пор и не завезли ни одной надёжной отказоустойчивой ФС.
А судя по высерам шизоида Торвальдса, это случиться ещё нескоро.
не знаю, на практике ntfs ломалась несколько раз, а ext4 не выкидывала никаких сюрпризов. Это конечно не показатель, но это жизнь.
Как тебе это удалось? На винде много проблем, но только не с файловой системой.
Как правило, она живёт дольше, чем сам винчестер.
> Как правило, она живёт дольше, чем сам винчестер.Не подтверждаю. В NTFS вполне возможно порушить MFT - и после этого вы таки пролетаете. Вообще совсем. Вплоть до BSOD при попытке монтирования. Или просто не цепляется. Хотя порой сторонние читалки и достают что-то - но вот это совсем не заслуга MS уже.
> NTFS может сломаться только в том случае, если кто-то разобъёт HDD молотком.Да щас. Видал тут чудиков - убили нтфс, поюзав диск в компе с глючным RAM. Заметили они это когда MFT склеил ласты и восстанавливать стало тупо нечего... офигенно, чо.
> А вот в линуксе так до сих пор и не завезли ни
> одной надёжной отказоустойчивой ФС.А вот btrfs кстати удалось запустить даже на совсем хламе сыпавшем бэдами, разложив данные со схемой DUP. Изредка чинит CSUM ERROR, но как тот еж - пищит, орет, но живет.
вы разницу между бэдами (диск вернул ошибку - можно пытаться обработать ситуацию) и "глючным ram" вообще не понимаете?Попробуйте поиграться на том, первом компе с btrfs - готов поставить вам двухлитровку жегулевского за статью о результатах. (мне на самом деле интересненько, но не более чем на два литра. Про zfs вот уже неинтересно, я знаю ответ.)
> вы разницу между бэдами (диск вернул ошибку - можно пытаться обработать ситуацию)
> и "глючным 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 сбоев копились бы фиг знает сколько, оно изредка глюкает при максимальной нагрузке, когда прогреется, а это ессно редкость. Что собственно и делает такие глюки сложными в отлове - мемтест вкалывающий по всей площади может не прогреть локально конкретный чип до максимально достижимых величин и вообще ничего не найдет - для этого надо более локализовано группу адресов активно долбить, чтобы все доступы одним и тем же чипам валились.
p.s. бонус по части убиения btrfs.Сильнее всего я смог убить его когда поюзал карту памяти в ридере (довольно паршивую и стремную - по поводу чего и btrfs). Там в какой-то момент карта при записи словила клин и из комы за разумное время не вышла. Пришлось передернуть. Карта очухалась - но результат был довольно забавный. Два суперблока из трех - испарились. Включая дефолтный, так что лобовое монтирование сообщало про чексум еггог в суперблоке, "ctree open failed" - гудбай. Что как бы не прикольно.
И это при том что суперблоки были в совершенно разных местах. Но у btrfs их по счастью три - и одна из копий таки осталась нормальной. Чинится это достаточно тривиально (не понимаю что мешает драйверу попробовать все три самому и цепануть хотя-бы в readonly, может хотели чтобы такие обсираки явно заметили). Так что поняв какой супер рабочий я восстановил из него и порушеные. И все заверте...
> Таки понимаю. Но CSUM ERROR он и в этом случае матюкается зачастую.ну, собственно, следующее же действие в этом случае - вырубать питание, может даже - без шатдауна, и разбираться, что повредили и чему тут на диске вообще доверять можно.
Проблема что этот error будет где-то в логах, которые не факт что заметишь в тот же месяц. Хотя бы - месяц.
Что там будет в логах event viewer - я хз, у меня настолько гнилой техники под виндой все же не бывало.Ну и эта ошибка - когда битые данные таки при чтении. А при записи никакого error не будет - будет контрольная инфа посчитанная с уже испорченного блока (если мы про машину с битой памятью) - так она и при чтении совпадет.
> Совсем очевидного дестроя вроде с наскока не вышло и фатально не развалилось
ну ок, будем считать, что хотя бы частично тест прошел.
(для справок, существует образ zfs, который просто вызывает kernel panic. scrub'ом не лечится, а offline fsck у zfs нет. "Разработчики" из iX закрыли тикет со словами "а это не наша проблема". Получить этот образ нельзя, поскольку личная и коммерческая инфа, и размер недетский [по понятным причинам, он снят не zfs send], к сожалению.)
> (для справок, существует образ zfs, который просто вызывает kernel panic. scrub'ом не
> лечится, а offline fsck у zfs нет. "Разработчики" из iX закрыли
> тикет со словами "а это не наша проблема". Получить этот образ
> нельзя, поскольку личная и коммерческая инфа, и размер недетский [по понятным
> причинам, он снят не zfs send], к сожалению.)Оффлайновый fsck у ZFS есть и называется zdb. Вот там можно поковыряться над битым образом, что называется "от души".
У Z-пула есть фича монтирования на предыдущую закрытую группу транзакций, когда обычное не помогает:
zpool import -F <poolname>.
"Поддержка команды "zpool import -F", позволяющей перемотать поврежденный пул к состоянию, соответствующему более ранней группе транзакций, что позволяет с высокой вероятностью восстановить повреждённый пул из состояния FAULTED."
> Оффлайновый fsck у ZFS есть и называется zdb.Хороший такой fsck - не умеющий писать. Он не способен решить ни одной проблемы, тем более автоматически. Это не то что не fsck, это даже не dchek 70х годов. Включая хотя бы банально понять причину паники. (хотя, возможно, и мог бы помочь проследить ее до потрохов zfslib, только его тогда самого пришлось бы в отладчике запускать)
Тот пул импортируется (собственно, владельцу было некуда деваться и он год так с этим пулом и жил). scrub виснет. Попытка обращения к определенным файлам - kernel panic. closed, notabug.
Вот такие альтернативно-одаренные разработчики в iX. У них 100% воспроизводимый крэш - notabug, не повод даже точно определить, где крэшится.
> потрохов zfslib, только его тогда самого пришлось бы в отладчике запускать)А я подсказал тебе как отладчика к дохляку цепануть и даже относительно сносно разработчикам отдать, без особого сливания данных даже.
> Вот такие альтернативно-одаренные разработчики в iX. У них 100% воспроизводимый крэш -
> notabug, не повод даже точно определить, где крэшится.А как они его воспроизводить в своих пенатах должны? :)
> ну, собственно, следующее же действие в этом случае - вырубать питание, может
> даже - без шатдауна, и разбираться, что повредили и чему тут
> на диске вообще доверять можно.Можно для начала 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], к сожалению.)А как тебе вон тот способ подбить автомобилем вертолет? Никак не могу придумать почему бы это не сработало. И образ слать никуда не надо...
ext4, если ты не в курсе - "является всего лишь некоторой адаптацей под современные требования" разработки, на десять лет старшей чем fat. Причем не сказать что чем-то лучшей или более надежной даже - скорее несущей груз совместимости с оборудованием, которое уже в 80е годы было мертво, и который не стали воспроизводить в microsoft.Сравнивать с нормальными системами, на идеях начала 90х, а не начала 70х, действительно, никакого смысла.
И тем более - с системами на идеях начала 2000х, когда компьютеры перестали быть большими и стало можно многое недоступное до того.
Только ext4 эволюционировала очень сильно. Более современные, может, и имеют возможности поинтересней, но не отличаются надёжностью и производительностью. На сегодня на роль универсальной фс общего назначения у ext4 нет конкурентов, поскольку она лучше во всём одновременно. Для флешек с ограниченным ресурсом f2fs поинтересней остальных вместе взятых будет правда.
> Только ext4 эволюционировала очень сильно.fat тоже немножко отличается от msdos v1.0, но вы этого предпочли не видеть
> Более современные, может, и имеют возможности поинтересней,
> но не отличаются надёжностью и производительностью.угу, конечно же, это ж не на ext4 "silent corruptions", это ж на zfs, или, там, ntfs ?
Ох уж эти сказочники, перепевающие глупые сказочки. Производительность там тоже не айс, если только не отключить к чертям журнал - после чего не айс станет надежность.
> Для флешек с ограниченным ресурсом f2fs поинтересней остальных вместе взятых будет правда.
очередная сказочка, от тех, кто ни ухом, ни рылом - ни для чего (кстати, тот же самый самсунг) ее придумал, ни как она на самом деле должна работать.
> у ext4 нет конкурентов, поскольку она лучше во всём одновременно.
от того что вы бубните эту мантру - устаревшая на двадцать лет fs не сделается "лучше во всем" ни на копейку.
>если только не отключить к чертям журналЕсли отключить журнал, производительность упадёт раз в 100. Привет. Да и ничего особенного, будет ext2 с надёжностью примерно как у fat32. Барьеры отключать суицид конечно, это фактически основной оплот её надёжности, но journal_data_writeback вполне безопасно использовать, я проверял неоднократно. От lazytime потенциальных проблем едва ли не больше. Только fsck прогонять всё же придётся после жёстких выключений.
>Производительность там тоже не айс
Производительность на одном уровне с ntfs (наиболее быстрой и производительной фс), надёжность и безопасность на порядки выше.
>как она на самом деле должна работать
Я знаю, как она работает, и этого вполне достаточно.
>устаревшая на двадцать лет
Ммм это ложь. Не стыдно?
> Если отключить журнал, производительность упадёт раз в 100. Привет.лол. Дальше можешь не продолжать.
> лол. Дальше можешь не продолжать.Я проводил различные эксперименты на ssd, это так, вся производительность ext4 зависит от журнала.
Очередной "эксперт" с Opennet.
> Очередной "эксперт" с Opennet.Факты вещь упрямая, бро.
когда факты противоречат логике и здравому смыслу - разумный человек начинает искать проблему в постановке эксперимента.Неразумный - публикует статью о самозарождении мышей из грязного белья, или пишет комменты о том что ext4 с журналом, оказывается волшебным образом в 100 раз производительней.
>волшебным образом в 100 раз производительней.К чему придираться придираться к словам? Больше аргументов нет? Это называется художественный приём.
> Факты вещь упрямая, бро.А фактовед знает про FTL, GC и прочие чудеса? Стократная разница - она стабильно держится? А то два запуска одного и того же на SSD/SD/usb флехах/... совершенно не обязаны отработать за одно и то же время :)
И вы хотите сказать, что с *отключенным* журналом ext4 работает *медленнее*, чем со включенным?
Именно так. Например, доступ к файлам происходил значительно медленнее. Скорость передачи тоже была не стабильна. Сейчас не скажу, что мне больше не понравилось, результаты тестирования чтения или записи, но вывод был совершенно однозначный: фантазиям из интернета про отключение журнала лучше не верить. При этом, есть возможности, действительно влияющие на производительность.
Так вот кто тесты на phoronix делает :)
> Так вот кто тесты на phoronix делает :)Не совсем. Фороникс проводит странные синтетические тестирования различных синтетических бенчмарков на странном железе. Я среди прочего выполнял тестирование в реальных условиях на реальных данных, упирающихся в io, для чего и был приобретён ссд тогда и для чего это всё и затевалось, поэтому общего тут мало.
методология - да, сходная.В смысле - "главное не пытаться разбираться, почему результаты именно такие".
> методология - да, сходная.
> В смысле - "главное не пытаться разбираться, почему результаты именно такие".По крайней мере данные результаты легко объяснить. Функции ext4 завязаны на журнал, без него она дефективна. Такое объяснение выглядит крайне логично, я тоже долгое время верил что отключение журнала может чем-то помочь. Но потом сравнил (несколько раз в различных условиях) и пришёл к определённым выводам. Если бы это был рабочий способ повышения производительности, то им бы пользовались все, ведь внезапное отключение это призрачная угроза.
> По крайней мере данные результаты легко объяснить. Функции ext4 завязаны на журнал,объяснить что небо на землю не падает, потому что боженька так устроил - можно, но механизм гравитационного удержания атмосферы понять это не поможет.
У вас - "боженька устроил".
> без него она дефективна. Такое объяснение выглядит крайне логично, я тоже
оно выглядит совершенно алогично. Главное - верить.
И ни в коем случае не искать проблему в построении своих тестов.> Если бы это был рабочий способ повышения производительности, то им бы
> пользовались все, ведь внезапное отключение это призрачная угроза.им активно пользовался гугль еще пятнадцать лет назад. Не исключаю, что и по сей день использует.
Мань, 15 лет назад ext4 не было и она не могла использоваться в продакшене. Я не понимаю, зачем отрицать очевидное и обвинять меня в некомпетентности в каждом ответе, при этом не предоставляя совершенно никаких аргументов.
> Мань, 15 лет назад ext4 не было и она не могла использоваться в продакшене.назови десять принципиальных отличий между той ext4 которая была пятнадцать лет назад и тогдашней ext3 "уже почти совсем но немного уже готовой для продакшна".
Особенно смешно - учитывая что обе получены cp -R ext2 ext$n+1
"аргументы" вида "да exfat то же самое что fat32" мы уже от тебя видели.
>десять принципиальных отличий между той ext4 которая была пятнадцать лет назадЛогика работы экстентов и организации свободного места (фрагментация), совершенствование журнала и внедрение барьеров (что значительно повысило устойчивость перед отключениями), добавление верификации метаданных и оптимизация доступа к данным, среди прочего инлайнинг файлов и директорий (что также значительно повышает производительность), ускорение процесса восстановления (без негативных сайд эффектов в виде рассыпавшихся данных), эффективность работы на больших массивах данных (20 терабайт на диск сегодня уже не фантастика), продолжать можно долго, но почему это я должен что-то доказывать? Если ext3 и была "ext2 с журналом", то ext4 — уже совершенно другая система.
>>десять принципиальных отличий между той ext4 которая была пятнадцать лет назад
> Логика работы экстентов и организации свободного места (фрагментация), совершенствование
> журнала и внедрение барьеров (что значительно повысило устойчивость перед отключениями),барьеры появились сильно постфактум - и я хорошо помню, что именно привело к их появлению.
Нет, у ext2 этой проблемы в таких масштабах не существовало.> добавление верификации метаданных и оптимизация доступа к данным, среди прочего инлайнинг
> файлов и директорий (что также значительно повышает производительность), ускорение процессаа это и тем более сильно позднее.
То есть все это - мелкие постепенные улучшизмы, большей их части в пресловутом 2005м, когда сделали cp -R - не существовало. flex_bg, dir_index, sparse_super - все это тоже появилось потом.
Структура fs осталась ровно та же - никаких революционных изменений, типа замены линейного списка битмэпами, так почему мне фанатики рассказывают что эти - разные, а вот fat весь одинаковый?
> доказывать? Если ext3 и была "ext2 с журналом", то ext4 —
> уже совершенно другая система.про ext3 ее фанатики говорили примерно то же самое примерно в том же самом 2005м. А вот разработчики говорили другое - "ну да, конечно, есть ньюансы, но пользоваться ext2 мы тебе не советуем - вот посмотри на этот и этот патчи - их когда-нибудь кто-нибудь бэкпортирует туда, но не мы и не сегодня".
Гугль, естественно, бэкпортировал - и продолжал ее пользовать, кажется, по 2010й, но в паблик эти патчи не попадали. В 10м мигрировал на ext4 без журнала - и, подозреваю, до сих пор там.
Ну и какую-же волшебную ФС ты нам противопоставишь?
А на счет тестов с отключением журнала я вполне верю, чего на свете не бывает.
главное верить что ext3 и ext4 ничем не отличается ))пох ты реально троль
принципиально - разумеется, ничем (вообще-то это считалось плюсом, а не минусом). Код - разный, писали разные люди в разное время, и общий первоисточник - код ext2 лохматых времен, структуры данных - те же.То есть если вы поотключаете новомодные фичи ext4, и отломаете проверку в драйвере ext3 - он с грехом пополам и парой паник - кое-что с нее прочитает.
А вот с exfat так не получится - драйвер fat32 ее прочитать не сможет абсолютно никак, даже если вручную подсунуть ему правильные смещения и наплевать на "модные фичи" типа таблицы перекодировок.
Поскольку там идея была как раз не в эволюционном развитии, а в том чтобы раз и надолго избавиться от старых грабель.
> По крайней мере данные результаты легко объяснить. Функции ext4 завязаны на журнал,
> без него она дефективна.EXT4 это такой EXT2 + журнал + хеширование дир + экстенты + delayed alloc. Если так, по большому счету. Об этом догадывается даже спиди-гонщик пох. Который, кстати, что-то имеющее отношение - кодил, если не ошибаюсь. Втирая ему про функции - не боишься ламернуться? Сорц то читал, покажешь пруф своего заявления хоть в каком фрагменте кода EXT4? У меня дерево сорцов есть и я проверю, чисто из любопытства. Мне на уровне технологий интересно как можно что-то тормознуть перестав работать с журналом.
Потому что кроме всего прочего журнал подразумевает лишние действия. Которые сами по себе ничего ускорить не могут. Как можно ускорить работу чего-то перестав делать ряд действий - некая мистика. Не то чтобы это вообще абсолютно невозможно, но чаще всего это либо ошибка эксперимента, либо неучтенный фактор, либо какое-то очень экзотичное взаимодействие например вот конкретно того очень странного комбо софта и железа, весьма уникальное и атипичное.
Предложенное объяснение - никуда не годится! Потому что ничего не объясняет на уровне которых проглотили бы те кто хоть немного понимает как ФС работает. Пох едко и популярно это объяснил.
> Такое объяснение выглядит крайне логично, я тоже долгое время верил что отключение
> журнала может чем-то помочь.Оно и помогает. Просто по дефолту ext4 журналит только метаданные. В обычных ворклоадах это не такой большой % - разница маргинальная. Но в ряде случаев можно упереться в интенсивную работу с метаданными, и там разница может стать ощутима. Ну например попробуй создание/удаление разлапистых иерархий на время. Только учти кеши, GC в ssd и все такое прочее, мерять заскоки фирмвари накопителя или крутизну кеширования не интересно в этом контексте.
Собственно такое журналирование - компромисс. Оно плюет на то что случится с данными, но по крайней мере не дает развалиться метаданным. Так что после краха ФС хотя-бы логически консистентна. Что впрочем не гарантирует консистентности данных в файлах.
> Но потом сравнил (несколько раз в различных условиях) и пришёл к определённым выводам.
Определенные выводы насчет дефолтного журналирования ext4 - простые: в обычном случае он не слишком то и мешает. Но вот путь к этом выводу и объяснения наблюдаемого - на уровне шамана с заячьей лапкой.
> Если бы это был рабочий способ повышения производительности, то им бы
> пользовались все, ведь внезапное отключение это призрачная угроза.Гугл IIRC без журнала на серверах. Но тут надо понимать что это - гугл. У них там оверлейная мегаструктура поверх этого натянута и дело сервака - пулять запрошенные данные в сеть, да побыстрее. А если они окажутся битые или потерянные - с этим другие алгоритмы на других уровнях разберутся. Зато им так совершенно пофиг если сервер сдохнет или заглючит. И зачем им при этом супернадежность? Она по другому делается. Сие впрочем не означает что вы сможете так же.
Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2 и в 1.5 раза ext2? И ext3 в 1.2 раза быстрее ext2? На этот раз я использую максимально близкие к реальности цифры. Кеширование интересно в контексте журнала и повышения производительности связанным с кешированием журнала. Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых файлов — если они обнаружены, это повод задавать вопросы. А внезапные отключения ему не грозят.
>ext4 в 2 раза быстрее ext2 и в 1.5 раза ext3selffix
> Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2
> и в 1.5 раза ext2? И ext3 в 1.2 раза быстрее
> ext2? На этот раз я использую максимально близкие к реальности цифры.
> Кеширование интересно в контексте журнала и повышения производительности связанным с кешированием
> журнала. Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых
> файлов — если они обнаружены, это повод задавать вопросы. А внезапные
> отключения ему не грозят.Попробуй провести свои эксперименты на старых добрых хардах, предварительно подготовленных затиранием блинов нулями.
> Попробуй провести свои эксперименты на старых добрых хардах, предварительно подготовленных затиранием блинов нулями.Упор, я так понимаю, тут на "старых" -- т.е. без (device-managed) SMR? ;)
>> Попробуй провести свои эксперименты на старых добрых хардах, предварительно подготовленных затиранием блинов нулями.
> Упор, я так понимаю, тут на "старых" -- т.е. без SMR? ;)Разумеется. Причём лучше взять не более терабайтных по объёму, и таких, про которые известно, сколько внутри блинов и какие обнаружены баги у фирмвари. ;)
> Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2У ext4 относительно ext2 в активе как минимум:
+экстенты.
+хэширование дир.
+delayed alloc.И все это было явно не для красоты.
> и в 1.5 раза ext2?Это повтор предыдущего вопроса. Я сорвал анониму стэк?
Если это было про ext3, то у ext4
+экстенты
+delayed alloc> И ext3 в 1.2 раза быстрее ext2?
2vs3:
+хэширование дир
Может какие-то еще оптимизации которых я не помню или не знаю.> На этот раз я использую максимально близкие к реальности цифры.
Эти цифры ... очень зависят от паттернов доступа. К ним есть разумные предпосылки в виде фич новых версий ФС.
> Кеширование интересно в контексте журнала
Не понимаю. Журнал не подлежит кешированию. Ведь если питание слетит или система ребутнется, кэш как раз и накроется. А вот журнал в этот момент как раз очень сильно понадобится. Но где ж его брать если он в кэше был? Или имеется в виду нечто типа отдельного девайса для журнала?
> и повышения производительности связанным с кешированием журнала.
...?
> Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых
> файлов — если они обнаружены, это повод задавать вопросы. А внезапные
> отключения ему не грозят.Если это про гугла - они просто все сделали иначе. Есть "распределенный алгоритм" который этим занимается. Гугловское добро не идет к ФС и не просит дать файл, оно просит распределенный алгоритм вынуть данные. Тот делает запрос к какому-нибудь серверу из подходящих. Тот отдает данные. Или не отдает. Или отдает битые. В первом случае ок, в втором и третьем запрос будет повторен на какой-нибудь другой сервер.
Такие вещицы могут оперировать даже не чексуммами а скорее хэшами и это не только чексум но и способ адресации. Основы таких штук гуглятся по словам типа content addressable network. Где-то рядом можно познакомиться с каким-нибудь ipfs...
> Мне на уровне технологий интересно как можно что-то тормознуть перестав работать с журналом.Он же на SSD ставил свои странные опыты. Это ненаучно. Надо было проводить тесты на предсказуемых и понятных HDD с хорошо известными характеристиками, висящих на каком-нибудь стандартном и хорошо известном интерфейсе. А у SSD невесть что на уме у контроллера в любой момент времени и в каком реально состоянии те ячейки.
>что на уме у контроллера в любой момент времени и в каком реально состоянии те ячейкиЕсли бы это было 1 раз... Я умею в методологию и тестирование проводилось несколько раз по кругу, всё учтено, но значения при этом всегда одинаковые независимо от очерёдности. Диск был совершенно новый к тому же.
>>что на уме у контроллера в любой момент времени и в каком реально состоянии те ячейки
> Если бы это было 1 раз... Я умею в методологию и тестирование
> проводилось несколько раз по кругу, всё учтено, но значения при этом
> всегда одинаковые независимо от очерёдности. Диск был совершенно новый к тому
> же.Значит, как выше было замечено, у тебя что-то неправильное в методологии.
Из чего это следует?
> Он же на SSD ставил свои странные опыты. Это ненаучно. Надо было
> проводить тесты на предсказуемых и понятных HDD с хорошо известными характеристиками,У SSD и HDD довольно разные характеристики - и таки знание о перфомансе на HDD не сильно поможет в оценке работы на SSD. SSD можно более менее научно тестить. Но канительно и можно облажаться.
Например:
1: trim всей поверхности
2: mkfs
3: бенчи
4: goto 1 (c другой ФС/конфигурацией)
>> Он же на SSD ставил свои странные опыты. Это ненаучно. Надо было
>> проводить тесты на предсказуемых и понятных HDD с хорошо известными характеристиками,
> У SSD и HDD довольно разные характеристики - и таки знание о
> перфомансе на HDD не сильно поможет в оценке работы на SSD.Спасибо, КО, просветил. Но речь была об оценке функционирования файловых систем, а не аппаратуры.
> SSD можно более менее научно тестить. Но канительно и можно облажаться.SSD _нельзя_ научно тестировать (что такое «тестить», анон? Что-то связанное и тестикулами?), поскольку проприетарные контроллеры SSD и их фирмвари — терра инкогнита. Ты никогда даже в общем приближении не знаешь, как именно оно работает с ячейками и что конкретно делает. Ты даже не знаешь, сколько на самом деле ячеек внутри. Твой максимум — верить рекламе производителя. Даже что делает trim — ты тоже не знаешь. ;) Да и не имеет оно отношения к файловым системам.
А у хардов есть несколько измеримых свойств, от которых можно отталкиваться при сравнении (например, скорость вращения шпинделя и количество блинов), и кое-какие стандартизированные программные интерфейсы к потрохам (S.M.A.R.T.). Ничего такого для SSD нет: что написано в рекламном буклете, тому верить на слово.
> Но речь была об оценке функционирования файловых систем, а не аппаратуры.Если кто еще не понял: на 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 поверхности заскипал стирание, а второй туповэйтил. Второй ФС в результате подсунули более плохие стартовые условия чем первой.
++++++
>"silent corruptions"Там чёт на ссд проблемы были если я верно помню, железоспецифичные баги. То ли дело xfs, зануляющая файлы, да? Ext4 у меня рассыпалась только по времена ext4dev, потом появились барьеры и она стала совершенно беспроблемной.
>fat тоже немножко отличается от msdos v1.0
Не особо. Потому что fat32 осталась в 90х и extfat это fat32.
> fat32 осталась в 90хВ 2000-2005, флешки форматировали в FAT16, а 2005-2015 - в FAT32. Да и сейчас наверное тоже.
> В 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.
(не говоря уже о том, что там нафиг не нужны сотни гигабайт)
О, робот, кто тебя написал? Я пытался анализировать твоё сообщение и пришёл к выводу, что ты - робот, который конструирует грамматически правильные предложения, но, к сожалению, не имеющие смысла.
> О, робот, кто тебя написал?боюсь, робот, ты обознался.
> но, к сожалению, не имеющие смысла.
для тех у кого нет мозга для понимания написанного - к сожалению, да.
и нет, exfat ни разу не fat32.
> и нет, exfat ни разу не fat32.Спорное заявление, fat32 была ещё в 95 венде и exfat это изменённые поля и немного костылей и подпорок. На флешках не так заметно, но сама её суть довольно дефективна и она совершенно не изменилась.
> Спорное заявление, fat32 была ещё в 95 венде и exfat это изменённыеваша ext2 написана в 92м. По мотивам systemV fs, придуманной в каком-нибудь 76м.
Все что с тех пор добавили - это "измененные поля и немного костылей и подпорок".
На быстрых дисках не особенно заметна, но сама суть, ориентированная на очень медленные, очень ненадежные и очень малоемкие носители (поэтому и размазывали метаданные с inodes ровным слоем по всему диску) - ничуть не изменилась.
Более того, все еще можно создать fs, читающуюся драйвером ext2 (в некоторых случаях - просто поудалять новые фичи с уже существующей).У exfat с fat32 общего - только сама концепция fat. Форматы - разные. Более того, в exfat fat не является единственным местом где может храниться информация о блоках файла. Структуры данных на диске - разные совершенно. Но религиозным фанатикам разница все равно не видна.
Может хватит сравнивать несравнимое? Лучше сравнивать ext4 с ntfs (образца так эдак после 2010 года, потому что раньше были проблемки — у ntfs). Я вот не помню, исправили или нет у fat проблему с чтением файлов, они читались в порядке записи и никак иначе. Ничего кардинально нового я там не вижу. Да, лучше журналируемых подходит для флеш памяти (не ссд), но и только. Ext4 же всё это время претерпевала значительные изменения.
сравнивайте.
Только вот в моей практике - "раньше были проблемки" у ext4 - вплоть вот до полной неработоспособности. А с ntfs у меня на десятках систем - почему-то не было ни одной проблемы, включая, на удивление, и линуксы - что, интересно, я делал не так?> Ничего кардинально нового я там не вижу.
потому что не хотите.
> Да, лучше журналируемых подходит для флеш памяти
для rotating drive-то, журналируемые, с бесконечным дерганьем головами к журналу-к области данных (причем запись в журнал у нас в обход элеваторных алгоритмов) - самое то были?
> Ext4 же всё это время претерпевала значительные изменения.
"ничего кардинально нового я там не вижу". Кстати, в каком там году ntfs научилась хранить мелочь напрямую в mft? (это к вашему inlining)
Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если включить какое-нибудь сжатие) не перестают удивлять и сегодня.>с бесконечным дерганьем головами к журналу
Там совершенно другие головы, например. К тому же он кешируется в памяти?
>у ext4 - вплоть вот до полной неработоспособности
Можно подробности? Желательно после 2007 или когда там барьеры подвезли.
> Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если включить какое-нибудь сжатие) не перестают удивлять и сегодня.А меня в 2020-ом поражает нехватка inode-ов в ext4. Форматируешь какой-нибудь раздел на 512 мегов для хранения многих мелких файлов с дефолтными настройками, и огребаешь кучу геморроя при использовании. И такие проблемы только у ext-а. У reiser4, xfs, jfs таких проблем нет.
Самые маленькие разделы у меня 4 терабайта. Но и когда по 1 терабайту были нехватки инод ни разу не возникло. А на 0.2тб и данных столько не было. Это просто умолчания, на маленьком разделе хочется больше пространства под данные и меньше терять под метаинформацию. Если знаешь заранее. что понадобится много, их можно попросить.>2020
>512 меговотличная шутка, лет на 30 опоздала.
> отличная шутка, лет на 30 опоздала.на 20. В начале 2000х я проблемы с нехваткой inodes еще помню.
Но тогда не было никакой ext4. А когда появилась хоть как-то живая ext4 - "разделы в 512 мегабайт" бывали только в каком-нибудь /boot - ему inodes хватило, он не жаловался. А 512 мегабайт - иногда не хватало.(todo: открутить и выкинуть из жабиксового темплейта ненужные проверки inodes вместе с историей и триггерами, они никогда в жизни не сработают, и ломаются на fs, ничего не слышавших ни о каких рариретах 76го года.)
> Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если
> включить какое-нибудь сжатие) не перестают удивлять и сегодня.ну вот я не наблюдаю какой-то катастрофической деградации на ntfs'ных дисках _десятилетнего_ возраста. Они, разумеется, не забиваются и не забивались под завязку, и да, сжатие я всегда считал дурным выбором (и тем почти спасся от очень малоприятных проблем в zfs - если бы не прозевал что обо мне позаботились и включили его в еще одном месте ;-) - возможно, если бы оно активно использовалось, что-то бы изменилось. (в конце-концов, ms зачем-то сует в планировщик дефрагментатор, хотя у юзеров и немного шансов что он успеет сработать)
К тому же в многозадачной системе не нужно отсутствие фрагментации, ей нужен правильный планировщик io. (а у нас - 12309)
> Там совершенно другие головы, например. К тому же он кешируется в памяти?
так журнал же ж! его нельзя кэшировать, в том и суть.
> Можно подробности? Желательно после 2007 или когда там барьеры подвезли.
когда подвезли, мы уже на xfs перешли (уже не вспомню что именно в той среде мешало нам выключить журнал, а с включенным оно тормозило в самые неподходящие моменты. К тому же про гугля мы тогда не знали, он умел хранить свои секретики). Так что полных крэшей, когда уже проще плюнуть на пропавшие данные и не пытаться ничего выковыривать, наверное, после ~2008го лично я уже не видел, только "massive filesystem corruptions" и "minor silent corruptions", угу. Но эти хотя бы исправлял fsck и md5sum позволял потом выявить испорченное.
Что на фоне моих прошлых пяти лет, прожитых в основном с ufs, все равно выглядело, мягко говоря, бледненько.
То есть вот привычка хранить рядом с крупными файлами их md5 - она у меня примерно тех времен, когда "барьеры подвезли", а данные не портить почему-то все равно не получалось. В начале 2000х у меня такой не было, и как-то обходилось. Может потому что диски были сильно меньше.Но обратите внимание - ntfs живет с еще более ранних времен, и по сей день.
>сжатие я всегда считал дурным выборомА с чего так, если места дефицит? Оно там правда очень небольшое, в угоду производительности.
ну типа если места дефицит - надо найти диск побольше, а этот положить на полку. Потому что диски это только деньги, а время, которое даром тратится на ненужные сжатия-разжатия - мое. Не говоря уже о возможных глюках (кстати, может по этой причине у меня ntfs-то и не портилась? Там, правда, есть пара мест, где винда включает ненунжосжатие без спросу.)
>диск побольшеА если раздел?
>надо найти диск побольше
Ну ты же деньги дашь?
>>диск побольше
> А если раздел?найти диск побольше и увеличить раздел при переносе? Или просто смонтировать вместо раздела.
Ну или пользоваться zfs, которой никакие разделы не уперлись. (ну или lvm, кто совсем ту...э...бесстрашный)
>>надо найти диск побольше
> Ну ты же деньги дашь?себе-то? Конечно дам, новый диск, а не губная помада, чай.
Речь-то шла о том, как я для себя поступаю. У меня, напомню, "разделов" в 512 мегабайт нет окромя /boot, да и тот на legacy системах, уже лет двадцать. А васяны пускай страдают "от ужастной нехватки inodes", сами себе разложив грабли, сами их преодолевают.
> А с чего так, если места дефицит? Оно там правда очень небольшое,
> в угоду производительности.На медленном диске, типа механики, кстати, прочесть и распаковать LZ4 или LZO может быть быстрее чем прочесть более крупный объем без сжатия. По поводу чего сжатие иногда даже ускоряет работу с диском.
>ms зачем-то сует в планировщик дефрагментаторОна много чего туда сует. Замучаешься выгребать. Что интересно, в XP еще не было такого безобразия. Додеградировали до 10.
>>с бесконечным дерганьем головами к журналу
> Там совершенно другие головы, например. К тому же он кешируется в памяти?Э-э-э ... и напуркуа тогда вообще журнал сдался? Чтобы лучше данные портить? 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.
Я использую data=writeback. Данные не журналируются, но метаданные вполне себе да. И барьеры есть. Журнал нужен, чтобы не повредить метаданные. Потому что если они повредятся, фс резко поплохеет и потерей пары временных файлов из кэша браузера (уже удалённых) не отделаешься. Журнал периодически синхронизируется с памятью, но происходит это периодически, а не прямо сейчас. Lazytime позволяет значительно минимизировать записи на диск, но время изменения файлов в случае внезапного отключения может сильно пострадать.
> Я использую 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 очень здорово уменьшают шансы повиснуть именно в момент записи метаданных.
Устаревшими = предыдущими консистентными? Так это же прекрасно, битые файлы нам не грозят. Синхронизация разве проводится не достаточно часто, что забить на несколько секунд сверхважных изменений в данных? Заодно передаю привет https://www.opennet.dev/opennews/art.shtml?num=50148
предыдущими консистентными - метаданными. То есть соответствием inode indexes и тому что в них самих написано. fsck счастлив.А предыдущие консистентные _данные_ внутри этой inode - ниоткуда не возьмутся, они уже давно перезаписаны вообще другой информацией, а то что там должно быть - лежит где-то еще, но на это место не ссылаются метаданные, мы их "откатили" (поэтому ты не сможешь восстановить его из lost+found). То есть это именно битый файл.
Если "забить на несколько последних испорченных файлов" - то да, но, к сожалению, продолжением является - "а теперь угадай, какие именно - испорчены". Это не какой-то баг ext2+, а врожденная фича всех не-cow fs (а cow приносит с собой свои, тоже не всегда прекрасные).То есть ситуация от ситуации вообще без журнала отличается только отсутствием необходимости ждать fsck - ценой потери производительности на "достаточно частое" переписывание из пустого в порожнее (оно синхронное, что радости не добавит)
А вот откуда там у некоторых повышение производительности "в сто раз" - это действительно было бы интересно поизучать. Но у меня, увы, не наблюдается.
> Заодно передаю привет https://www.opennet.dev/opennews/art.shtml?num=50148
эмм... поведение больших баз данных на ненадежном физическом носителе - по-моему предмет исключительно академического изучения, не?
То есть, собственно, решение этой "проблемы" постгрезом - крэшнуться.
Хех, мы вроде уже выяснили, что "в 100 раз" — это ради красного словца? Я тогдапредположил, что это кеширование и без журнала оно менее эффективно (кэши фс я сбрасывал через троечку).Что до остального, разве барьеры не решают именно эту проблему? Я не помню, чтобы хоть раз у меня появились битые данные на ext4. На ntfs, впрочем, тоже — у неё проблемы с повреждением структур, но не данных.
>файлы либо нулевой длины, либо с прежним содержимым, либо исчезлиЭто, кстати к xfs, на ext4 такое маловероятно. Зачем проецировать опыт работы с дефективными фс на ext4?
>NTFSА там торрент клиенты все также жутко фрагментируют файлы, кроме малварного utorrent?
пользуюсь на винде малварным муторрент, поэтому не знаю ;-)P.S. что, реально настолько п-ц? ВСЕ вот прямо - все другие поделки не умеют prealloc? Уж что-что, а размер файлов в торренте всегда известен заранее. Создавать их в винде нативной программой без preallocation - это просто гейклуб какой-то, простите за выражение.
>реально настолько п-ц?С разряженными файлами просто дичь. А preallocation очень медленный. Не знаю уж что накостыляли в utorrent, чтобы это обойти.
> пользуюсь на винде малварным муторрент, поэтому не знаю ;-)
> P.S. что, реально настолько п-ц? ВСЕ вот прямо - все другие поделки
> не умеют prealloc? Уж что-что, а размер файлов в торренте всегда
> известен заранее. Создавать их в винде нативной программой без preallocation -
> это просто гейклуб какой-то, простите за выражение.Они умеют prealloc, но как-то странно. Упомянутый qBittorrent, например, при _снятой_ в настройках галке о сабже и при выборочном скачивании содержимого торрента всё равно пишет на диск всякий мусор предположительно такого размера, как у файла, который ты не хочешь скачивать и заказал не скачивать.
Я, пожалуй, постепенно плюну на этот хвалёный опенсорс и тоже перейду на мюторрент, хотя он не столь удобен, как qBittorrent.
>>NTFS
> А там торрент клиенты все также жутко фрагментируют файлы, кроме малварного utorrent?За все не скажу, а qBittorrent мне однажды сделал веселье. Деталей уже не помню, хотя писал об этом случае в комментариях, кажется. Было что-то, ЕМНИП, с неправильным определением размера ФС (один раздел на весь диск). Пришлось из Live-среды отрезать от ФС около гигабайта и выбросить во тьму внешнюю, дабы сохранить остальной терабайт живым. Получилось, ЧСХ. Зря не задокументировал подробностей, вот прямо жалею.
> сама суть, ориентированная на очень медленные, очень ненадежные и очень малоемкие носители (поэтому и размазывали метаданные с inodes ровным слоем по всему диску)- Вот тут Вы "слегка" :-) подзабыли. Ext2, не смотря на свой более старший возраст была ЗНАЧИТЕЛЬНО лучше по всем параметрам современной ему FAT (дешевая система для Кухарок - дешевая FS, от куда в MS было взяться хорошим (дорогим) разработчикам? Это потом, разбогатев, MS смог купить крутых UNIX-оедов для разработки технологии "NT").
Inodes, размазанные по диску ввиду их цепочности как раз значительно (в дополнение к кешированию) ускоряют работу механического диска из-за близости к данным (поступательное движения головки и ожидания на дорожке подхода нужного сектора), ну и повышается надежность. Мне, в былую тяжелую жизнь очень часто перепадали большие и достаточно новые диски с протертыми начальными цилиндрами, куда Вындовс складывал обе таблицы, достаточно было их отрезать.
> fat тоже немножко отличается от msdos v1.0, но вы этого предпочли не видетьИ где там экстенты или индексированные диры? :) А без всего этого он тормозной и на сколь-нибудь разлапистой иерархии встает колом.
> На сегодня на роль универсальной фс общего назначения у ext4 нет конкурентов, поскольку она лучше во всём одновременно.Ну это бред же. "Лучше" в чём? По-мне, так XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования.
>XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционированияОни уже перестали необратимо деградировать? В ext4 подпёрли костылями и вполне нормально. Единственный "недостаток" у ext4 — это ограниченное число инод, что на практике не так страшно. Лучше по всем параметрам использования.
>>XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования
> Они уже перестали необратимо деградировать?redhat уверяет, что да (точнее что нет, нам и раньше показалось, но сейчас - точно перестали)
В ufs - это вам кто-то вредную сказку на ночь опять рассказал, ничего там не "деградирует".> В ext4 подпёрли костылями и вполне нормально.
э... ну если это ок - то точно перестали, искренне соглашусь с редхатом.
> практике не так страшно. Лучше по всем параметрам использования.
главное - верить?!
> главное - верить?!Главное — опыт. Вот о ntfs я ничего хорошего сказать не могу, о xfs тоже. Да и о ext3, в принципе. При этом ext4 за годы использования повсеместно зарекомендовала себя исключительно положительно.
Про ufs2 я ничего не знаю, но опыт общения с ufs1 был довольно удручающим.
> Главное — опыт.опыт без попыток анализа - так и остается anecdotal evidence.
Я вот ничего плохого об ntfs сказать не могу - у меня ни одна сама по себе не сдохла, с 1994го года. Только вместе с полным необратимым разрушением носителей. И ни одного файла "просто так" не потеряла - только при повреждениях физической структуры.
Об ext2, в отличие от ext3 и 4 - тоже не могу.
C xfs были приключения, в виде регулярных крэшей - но это было до попадания ее в лапы redhat, и, полагаю, сейчас эти проблемы крайне маловероятны. Я ее не люблю и стараюсь не пользоваться, но отдаю себе отчет в том, что это - иррациональное желание, не имеющее адекватных технических оснований.Опыт с ufs2 и ufs1 лично у меня - "ни единого разрыва" (кстати, откуда он у вас "удручающий" и с чем вы ее сравниваете - c ntfs3 ? ufs2 - это примерно все тот же 2005й) , правда, я не использовал экстремальные варианты и избегал очевидно опасных.
Ооо, про ntfs я могу рассказать много хорошего, поскольку я спокойно пользуюсь и вендой. Нтфс из икспишечки (3.1) рассыпалась просто по расписанию и по любой причине (и без), нтфс из 7 рассыпалась уже реже, но подозрительно часто. Особенно заметно, когда место на системном диске кончалось. Приходилось устанавливать начисто, потому что восстановиться с лайвсиди она не могла. Да и 10 как выяснилось недалеко ушла. Неудаляемые каталоги ни с того ни с сего, неудаляемые файлы, битые файлы, разваливание на ошмётки от chkdsk (тут или исправит, или рассыпется в пыль)… Сколько всего было, и это даже без сжатия с шифрованием (с ними — сплошной кошмар). И да, диски были в полном порядке.Про использование ntfs через ntfs-3g и говорить нечего, у меня всего за пару лет использования практически в read-only (года так с 2018), она приобрела невосстановимое состояние и часть файлов случайным образом может отказаться удаляться. Нужно прогонять chkdsk и это плохо кончится, поэтому пользуется пока так. Фрагментация просто космическая (особенно на мелких файлах вроде профилей браузеров, тот же стим умеет правильно попросить ос и файлы не фрагментируются так).
Поэтому заявления на тему УМВР выглядят в высшей степени нездорово для меня.
> Нтфс из икспишечки (3.1) рассыпалась просто по расписанию и по любой причине (и без)Вот что я делал не так, что у меня не рассыпалась? Диски с ntfs из под xpшечки вон, лежат себе на полке по сей день - там обработанные и полуобработанные фотки, которые никогда не удалялись, и когда место кончилось - были убраны в архив с дисками.
Отдельно интересно что я делал не так на полу-production серверах, с 24x7 и прочими прибабахами, те, конечно, столько не жили, но вполне продолжали работать, когда я уходил из тех контор.> Особенно заметно, когда место на системном диске кончалось.
возможно, конечно, если очень старательно превращать диск в крошево, то к успеху непременно придешь.
Не то чтобы у меня совсем уж никогда не кончалось, но эти случаи были явно единичные (и уж точно не в линуксе)Отдельный вопрос - как за два года можно убить ntfs используемую в режиме "почти readonly"? Я, конечно, понимаю, что у меня-то немодный-немодный мамонтов кал какого-нибудь 2011го года (а ntfs'ным дискам, соответственно, поболее), и, возможно, ntfs3g с тех пор стали писать не руками а другим местом?
"BUT HOW?!" учитывая что она просто работала - что и зачем там с тех пор ТАК наулучшали?Что именно мне теперь не стоит апгрейдить - fuse, саму ntfs3g, ядро, или все вместе?
> Вот что я делал не так, что у меня не рассыпалась?Наверное не тащил с помойки навозную комплектуху и на неё не пытался ставить вин?
ну вот те диски, на которых по сей день, наверное, живет XP, поставленная в 2003м году, если подключить в правильные порты (кажется, все железо там еще правильных с ее точки зрения id, хотя тумбочка давно переделана под линукс а потом просто забыта) - они считай с помойки. Вынуты мной из сервера, обеспечившего мне ночную поездочку к хостеру (в той конторе было принято менять диски в сервере ровно один раз - случайный сбой, не случайный - нахрен с пляжа, в десктопы или в дискеты, простой обходится дороже и ночью надо спать). Один, похоже, и впрямь был слегка сбойный, второй вроде нет - но живы оба. Были, два года назад, когда подключал что-то оттуда прочитать.
Использовались, что характерно, первые пару лет для торрентов ;-) Но да, mTorrent, он умеет в prealloc ;-) Лежали на подоконнике рядом с платой, корпуса лишнего не нашлось ;-)Диск в офисном ноуте на прошлой работе - долго и героически умирал (леново, блин) и таки сдох окончательно, но сдох именно физически - то что еще читалось, вполне можно было скопировать.
То есть совсем помойного железа вроде как и не держал никогда, но никаких чудес и золоченных оплеток кабелей. Скорее - аккуратная эксплуатация и расследование странностей типа "не загрузилось", "стало виснуть", или "странные звуки из корпуса" (обычно все три - повод выбросить блок питания со вздувшимися конденсаторами. Кстати, самым дрянным оказался дорогущий thermaltake)
Ну и chkdsk в любом случае, вызывающем подозрения целостности.
кондеры перепаял и в путь. у меня перепаяная geforse gt 1800 до сих пор пашет. точнее рабочая лежит. но да старое оборудование как то более живучее . даж системник на селероне 1800(опять 1800))) работает. там правда жесткий тольк 40 гигов. но на нем у меня линей перепробовано куча. правда с кедами 4 решил не мучать его. до сих пор на нем стоит мандрива 2007. а ext что 4, что 5 очень даже приличная фс. вспомни лучше про крики про ext2.)))
> но да старое оборудование как то более живучееТолько холодное и маложручее. И к старости это никак не относится. Только к прожорливости и температурным режимам. А так - эээ вы вообще видели например современную мамку с полимерными конденсаторами и чтоб это сдохло? Они за обозримое время вообще не мрут вроде.
Но поскольку такие кондеры дороже - их в топовые модели ставят обычно. Принцип "как заплачено так и зафигачено" не отменяли.
> кондеры перепаял и в путьты будешь смеяться, но на дорогущем thermaltake с отсоединяемыми кабелечками - для "перепаять кондеры" оказалось нужно выпаять ВСЕ силовые ключи, и оторвать их разлапистые радиаторы, именно в этой последовательности, по другому - вообще никак. Неремонтопригодность = 100% (и, конечно же, те самые помоешные китайские электролиты рупь пучок)
Диск, кстати, после работы с ним начал как-то подозрительно похрюкивать. Но пока ntfs цела.
> вспомни лучше про крики про ext2.
не считая печальной истории с лимитом 2G - вот вообще не припомню ни одной проблемы с ext2. То есть там тоже были всякие "massive corruptions", при том что в те времена иногда было просто необходимо ставить именно самое распоследнее ведро, а не надеяться на штабильный дистрибутив, но меня они вполне счастливо обошли стороной. А потом линуксы пошли строем на помойку по несвязанным с fs причинам.
> "перепаять кондеры" оказалось нужно выпаять ВСЕ силовые ключи, и оторвать их
> разлапистые радиаторы, именно в этой последовательности, по другому - вообще никак.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
Чувак, у тебя наверняка что-то с питанием. В смысле — в розетке и/или в БП.
> Чувак, у тебя наверняка что-то с питанием. В смысле — в розетке и/или
> в БП.Да, я уже поменял место жительства, купил упс, и всё остальное. Емнип наиболее частые проблемы с нтфс были после бсодов всё же. Видел пару раз бсоды на 10, но стало намного лучше чем было прежде. А ещё 10 не приходится с кнопки перезагружать, даже если она зависает можно перезапустить видеодрайвер и она скорее всего раздуплится. Линукс же ребутался с кнопки из-за того что память кончалась, паники дело достаточно исключительное и происходят в основном из-за багов железа (под вендой это же железо как-то может работать без багов надо понимать).
>> Чувак, у тебя наверняка что-то с питанием. В смысле — в розетке и/или
>> в БП.
> Да, я уже поменял место жительства, купил упс, и всё остальное. Емнип
> наиболее частые проблемы с нтфс были после бсодов всё же. Видел
> пару раз бсоды на 10, но стало намного лучше чем было
> прежде. А ещё 10 не приходится с кнопки перезагружать, даже если
> она зависает можно перезапустить видеодрайвер и она скорее всего раздуплится. Линукс
> же ребутался с кнопки из-за того что память кончалась, паники дело
> достаточно исключительное и происходят в основном из-за багов железа (под вендой
> это же железо как-то может работать без багов надо понимать).Про столь ужасающие траблы NTFS здесь пишешь ты один, больше никто не пишет. Логика здравого смысла подсказывает, что эти проблемы специфичны именно для твоих условий. Проверяй их, стало быть.
>больше никто не пишетОстальным пофиг. Промелькало там что-то на экране и ладно — всё равно не поймёшь, что там написано.
>Логика здравого смысла подсказывает
Это не логика, это желание найти простое объяснение. Жёсткие косяки в проектировании (которые разработчики даже где-то когда-то признали) фанатам индусского проприетарного кода кажутся менее вероятными. Видимо по причине когнитивных искажений.
Не хочешь советов — проигнорируй и страдай дальше.
> Не хочешь советов — проигнорируй и страдай дальше.Я не страдаю. Наученный опытом, я учитываю теперь, что самая большая ошибка, которую можно совершить с дисками — это выбрать нтфс под хранилище. В 10 с ней всё _гораздо_ лучше, однако ntfs3g её разносит достаточно быстро, как выяснилось. И она всё ещё фрагментируется и тормозит (очень ощутимо). В связи с чем, любители 7 кажутся особо забавными.
К сожалению, для венды вариантов не много, но можно просто не хранить на ней ничего ценного. Она у меня даже в виртуалке запускаемой от случая к случаю рассыпалась (xp,7).
>> Не хочешь советов — проигнорируй и страдай дальше.
> Я не страдаю. Наученный опытом, я учитываю теперь, что самая большая ошибка,
> которую можно совершить с дисками — это выбрать нтфс под хранилище.
> В 10 с ней всё _гораздо_ лучше, однако ntfs3g её разносит
> достаточно быстро, как выяснилось. И она всё ещё фрагментируется и тормозит
> (очень ощутимо). В связи с чем, любители 7 кажутся особо забавными.
> К сожалению, для венды вариантов не много, но можно просто не хранить
> на ней ничего ценного. Она у меня даже в виртуалке запускаемой
> от случая к случаю рассыпалась (xp,7).Всё-таки поинтересуюсь: что ты с ней делаешь, что она у тебя рассыпается? Миллиарды хардов с ней как-то живут и даже всякие вредные торренты крутят.
Против фрагментации микромелкие придумали запускать по расписанию (по ночам) дефрагментатор. Если машина работает круглосуточно, он решает эту проблему.
Ничего особенного, всё как у всех. Создаю, удаляю файлы. Много файлов. Архивы, распаковка-упаковка. Файлы-файлы-файлы. Торренты тоже бывали конечно, надо же скачивать линукс для виртуалки хотя бы. Главное, не запускать chkdsk, чтобы она там в тихую что-нибудь не исправила (венда периодически сама её запускает при загрузке, даже если ты не просил). Лучше всего не перезапускать, т.е. полгода и более аптайма (опять же, чтобы при загрузке не починила). Ну и дефрагментация очень сомнительное занятие, даже если есть время простоя, двигать все эти терабайты туда-сюда сомнительное развлечение (которое создаёт ощутимые вибрации и греет диски). По ночам пк должен быть либо выключен, либо заниматься полезной ресурсоёмкой работой.
Кстати насчёт файлов, они таки бились. Фоточки бились целиком или частично, картиночки, видосики, архивы не проходили проверку… Даже на файлах, которые никто не трогал, кроме разве что дефрагментатора. Может, конечно, и не в нтфс дело, но смарт тесты были в порядке, а на ext4 такого не случалось.
> Миллиарды хардов с ней как-то живут и даже всякие вредные торренты крутят.Ну так там при бздыщ юзер чертыхается, переставляет систему и перекачивает торенты заново. А ничего ценного у них все-равно не было. Ну может какие фоты котят, но это они так и быть скачают из облаков и инстаграмов.
> Против фрагментации микромелкие придумали запускать по расписанию (по ночам) дефрагментатор.
> Если машина работает круглосуточно, он решает эту проблему.У большинства хомяков таки не работает. А технарям ночью внезапный тупняк компьютера тоже скорее анноянс.
Хранилки на винде и проч - блин, виндус сервер стоит конских денег и при том даже если бы он был бесплатным, он не имеет предложить вообще совсем ничего интересного, кроме дурного гимора с администрированием и вулнами.
ntgs3g он с ней делает.
> ntgs3g он с ней делает.Похоже на то.
>NTFS ни одного файла "просто так" не потерялаХа ха ха. На флешке chkdsk постоянно запарывал файлы. А уж как она любит складывать в кучу файлы, если ей не понравится имя.
Еще интереснее бывает если флеху или sd сдернуть без размонтирования. У некоторых вообще таблицы трансляции после этого слетают. И файлы выглядят очень интересно. Примерно как если бы вы их перемешали в блендере.
ntfs проклятая виновата! И лично Блин Гейц дотянулся!
> ntfs проклятая виновата! И лично Блин Гейц дотянулся!Не, в этом случае таки не гейц :). Но, гм, ntfs спокойно отдает такие файлы (если повезет и метаданные не перемешались так же). Просто фоточки выглядят ... очень интересно. Вот как раз несколько кусков, от разных файлов, с сбоями декодирования по границам этого, такие марсианские пейзажи получаются из фоток котят! :)
По-моему начиная с 10 мс взял пример с кде и флэшечки теперь можно дёргать относительно спокойно, если прогресс бар дошёл до конца.
> По-моему начиная с 10 мс взял пример с кде и флэшечки теперь
> можно дёргать относительно спокойно, если прогресс бар дошёл до конца.Настройки кэширования для сменных носителей (да и для хардов тоже) присутствуют в оффтопике ещё, наверное, с тех времён, когда про линукс никто не слышал.
>> По-моему начиная с 10 мс взял пример с кде и флэшечки теперь
>> можно дёргать относительно спокойно, если прогресс бар дошёл до конца.
> Настройки кэширования для сменных носителей (да и для хардов тоже) присутствуют в
> оффтопике ещё, наверное, с тех времён, когда про линукс никто не
> слышал.Как много пользователей туда заглядывало? К тому же настройки там по-моему для устройства задаются (или для буквы, не помню). Приемлемые дефолты для флэшечек появились только в 10.
>>> По-моему начиная с 10 мс взял пример с кде и флэшечки теперь
>>> можно дёргать относительно спокойно, если прогресс бар дошёл до конца.
>> Настройки кэширования для сменных носителей (да и для хардов тоже) присутствуют в
>> оффтопике ещё, наверное, с тех времён, когда про линукс никто не
>> слышал.
> Как много пользователей туда заглядывало?Это уже другой вопрос. :)
> К тому же настройки там по-моему для
> устройства задаются (или для буквы, не помню). Приемлемые дефолты для флэшечек
> появились только в 10.В диспетчере устройств в свойствах накопителя — вкладка «Политика».
Для флешек настройка называется «Оптимизировать для быстрого удаления». Она отключает кэширование.
> Она отключает кэширование....и превращает флешку в черепаху. Потому что совсем без кеширования да с убогим контроллером... мм...
>>XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования
> Они уже перестали необратимо деградировать?Они переживают носители, на которых первоначально размещаются. Прикинь, dump/restore делают своё дело на уровне блоков ФС и бэкапят данные в tar на другое устройство. А впоследствии, когда носитель уходит в мир иной, данные ресторятся на новый в той же файловой структуре, какими были изначально. Ничего не напоминает?
> В ext4 подпёрли костылями и вполне нормально.
> Единственный "недостаток" у ext4 — это ограниченное число инод, что на
> практике не так страшно. Лучше по всем параметрам использования.Только эта [Ext4] ФС не переживает своего физического носителя - время жизни ограничено. Поэтому что-то в ней оптимизировать на этот счёт нецелесообразно.
Ух, я уж думал что изену пересадили мозг. Ан нет, опасения были напрасны, его адеквата хватило только на 2 дня.
Не понимаю, в чём смысл переносить битые файлы. Там хотя бы есть возможность узнать, что они битые? Но с этим у всех кроме разве что zfs с btrfs сложности. Переносить разделы (и сжимать их), либо тарить содержимое со всеми возможными атрибутами (и сжимать тарбол) так-то можно с любыми фс, если что.
> Не понимаю, в чём смысл переносить битые файлы.Это iZEN. Он крут в откаблучивании странных действий, бессмысленно и беспощадно.
> XFS и UFS2 В РАЗЫ лучше Ext4 по многим показателям функционирования.XFS офигенен когда с метаданными работает - тормозит он и правда в разы сильнее ext4. Да что там, даже он даже btrfs перетормаживает в этом аспекте. Хотя не умеет и 10% от его возможностей.
А ufs2 - чего в нем офигенного, кроме того что господа офигели такой античный дизайн в 2020 году таскать? :)
Поделитесь пожалуйста в чем перелесть работы с метаданными в XFS? Есть инструменты восстанавливающие ФС после краша?
> Поделитесь пожалуйста в чем перелесть работы с метаданными в XFS?Прелесть, к сожалению, в обратную сторону - он при активной работе с метаданными жестоко тормозит. Никогда не видели как файл стирается *минуту*? На XFS так бывает :)
> Есть инструменты восстанавливающие ФС после краша?
Тот реверанс был про фирменную скорость работы с метаданными, которая мне почему-то не очень нравится, по поводу чего я и избавился у себя от XFSов.
> Игра "сосчитай сколько уже драйверов для этой фигни"по сути - полтора, не считая полуработающих.
То есть fuse'шный тормозной и глючный и две версии одного и того же - разработанного самсунгом.Выкидыш парагона не предназначен для использования - это ясно любому, кто в состоянии глянуть в его код. Обычная ср..ная самореклама.
> лучше бы для ZFS столько.
для zfs лучше бы один нормальный осилили - но, похоже, некому уже там. А самсунгу в телефонах и шибкоумных телевизорах его применить некуда, так что от него тут помощи ждать не приходится.
Но я таки надеюсь что ты и запилиш zfs.
ну, в принципе, готов набрать команду (у меня есть целых два знакомых, которые иногда в состоянии даже что-то в очередной раз за гуанокодерами исправить в ней).Осталось обсудить с тобой вопрос оплаты и финансовых гарантий оной - и мы немедленно пишем заявления по собственному желанию, сосредоточившись исключительно на улучшении zfs.
Полагаю, там не так много получится - мы не избалованные гломурные геи из гейареа, наверное, $150-250k/в год будет на первое время достаточно.
А пока ты не готов ТАК спонсировать эту разработку - извини, мы вынуждены работать на тех, кто нас оплачивает, а они в zfs не слишком заинтересованы. Скорее уж на какой-нибудь gluster удалось бы развести - но тот вполне успешно пилится на денежки redhat, им можно не помогать.
много воды пишите ...
Но только, если хочешь, чтоб в ядро взяли, придётся from scrach под правильной лицензией. ;)
а зачем ей быть в ведре? Те, кому оно на самом деле надо - поставят наше, правильное ведро, с нужными патчами - никто ж в здравом уме не тащит на хранилки самую распоследнюю версию.Там в самой zfs очень много чего есть такого, что надо почистить и перепилить (и местами лучше уже "from scratch", чем пытаться чинить нечинимое), последствия торопыжных улучшизмов, наскоков набигателей с конкретным грантом или тз от своих менеджеров наперевес, и просто засохших ошметков неясной субстанции. А сейчас по факту с каждым новым таким улучшизмом она становится только хуже - даже когда цели изначально абсолютно благие.
> gluster ... успешно пилитсяИ как наощупь, на что-то годится? Когда я его тыкал палочкой, клиент намертво зависал при банальном ls директории, смонтированной в тестовом режиме (или отладочном, не помню уже как он там назывался), если в ней было больше 8 или 16 файлов.
на ощупь - третья версия годится. Если потеря данных и split-brain не является фатальной проблемой. (то есть вот 200T дорогих сердцу домашних байтиков - все таки ссыкотно так складывать)Но вот когда читаешь официальную документацию (ту что от владельцев) - волосья на жеппе все же встают дыбом.
Впрочем, неофициальные советы от разработчиков еще интереснее - как тебе идея развернуть его поверх...zfs ? А вот они в этом ничего неправильного - не видят. (ну то есть - не видели. Совет относится к какой-то третьей версии, а они уже - седьмую выпекли. Ставить - не стоит ;-)
В отладочном режиме (что это вообще? metadata?) я, правда, ничего не монтировал, поскольку ничего и не собираюсь отлаживать.
Как это все живет с _мелкими_ файлами (что является редхатовским, но не моим use pattern) - не проверял, если что. Полагаю - хреноватенько, учитывая особенности реализации без выделенных серверов метаданных, хотя костылей и подпорок (разной степени стремности) под это место там и подложено.
В чем проблема с zfs в Linux? О чем речь?
zfs-0.8.2
@tonyhutter tonyhutter released this on 27 Sep 2019Supported Kernels
Compatible with 2.6.32 - 5.4 Linux kernelsНормально работает, развивается.
однако фигня реально быстрая
Если они удалили из кода реализацию "низких" FAT, не скажется ли это таким образом, что различная китайсякая апарасюра сможет читать только простые FAT либо только exFAT?
На десктопе это можно будет смонтировать на обычные разделы? Будет профит для зубастого хомячка?
> зубастого хомячка?Этому можно провод дать погрызть. Если совсем надоел - с 220.
вот и сиди теперь, как лох, без электричества.А я, пока не видно, пойду, пожалуй, запорный кран на трубе отопления пожую.
>> ограничение на число файлов в одной директории поднято до 65 тыс.Что-то как-то не очень-то и много
Ммм я тут давеча открыл каталог с 1кк файлов в фм, так он под гигабайт памяти сразу выжрал (и было это очень не быстро). Для мест, где можно применить fat, 65к — это уже слишком много.
Прикол в том что все эти эксперты позиционируется для использования в мобильных и фото, а с современными объёмами карточек 65к совсем не потолок, особенно когда камеры научились снимать овердофига кадров подряд для сведения во всякое слоумоушен
>ЭкспертыЭксфаты. Долбанная автозамена
камеры научились не складывать все эти файлы в один-единственный каталог, который потом невозможно разгрести даже если fs ничего против не имела - двадцать лет назад. ДВАДЦАТЬ лет, Карл!
По традиции ты готов отвечать вообще за все устройства, ты же не пустобрех какой-нибудь?
Вообще-то это был индустриальный стандарт, со всем этим DCIM/VENDOR__N.NNN/Нет, за поделки русских васянов, кладущих на стандарты член, отвечать не готов, но, боюсь, их проблемы не колебали ни в малейшей степени ни разработчиков exfat, ни программистов самсуня.
Большинство виденных смартов валило все в один DCIM/*И таки эта куча папок
1) Жутко бесит, потому что лепится фотиками хаотично по одному им ведомому принципу. Сортировать это потом неудобно.
2) Это обычный костыль убогости ФС.
> Большинство виденных смартовот дядюшки Ляо? У меня почему-то "большинство" виденных смартов придерживаются DCF.
> И таки эта куча папок
> 1) Жутко бесит, потому что лепится фотиками хаотично по одному им ведомому принципу.нет.
Это индустриальный стандарт. "Большинство фотиков" ему соответствует, тяжелая профессиональная аппаратура иногда имеет некоторую возможность тюнинга (в зависимости от чего сбрасывать счетчик, считать, как предписывает стандарт, только до 100, или все же до более адекватной современным меркам тысячи с риском что это не поймет автопринтер и т п)> Это обычный костыль убогости ФС.
давай, неубогий - вот у тебя образовалась каша из, положим, 40000 файликов с одинаково-бессмысленными цифровыми названиями (необязательно 8.3 и по порядку, это ж все враги придумали, мы можем сделать еще неудобнее и поименовать их какими-нибудь uuid'ами) в одной куче.
Как ты их разгребать-то намерен, вне зависимости от используемой fs?
> от дядюшки Ляо? У меня почему-то "большинство" виденных смартов придерживаются DCF.Дядюшка ляо тоже разный, всякие плохие дороги - тоже ляо. И таки они вроде в 1 диру валят, во всяком случае 9К файлов в 1 дире я видел. Грузилась дира довольно неспешно, сам не понимаю почему :)
> Это индустриальный стандарт. "Большинство фотиков" ему соответствует, тяжелая
> профессиональная аппаратура иногда имеет некоторую возможность тюнингаСтандарт стандартом, а фоты сортировать из этого барахла довольно неудобно. Потому что группируются по дирам по черт знает каким критериям. Даже знакомые хомяки на это плевались кислотой.
> поймет автопринтер и т п)
Честно говоря я ни разу не видел кого-то использующего какие там еще принтеры сразу с фотика.
> Как ты их разгребать-то намерен, вне зависимости от используемой fs?
По дате, например, что самое логичное. Ну не за день же я 40К нащелкал, в самом деле? И там это будет как минимум грубое деление по тематике/месту. Если там GPS теги или что-то подобное было, я вообще туда шелл отправлю вкалывать, на манер того чудика из миднайтовского треда. И он сам по координатам выдернет все релевантное, например.
А вот когда куча файлов в разных дирах и это не коррелирует с датой/местом/координатами и проч - это уже довольно неудобно. В шелле можно и такое на самом деле обтяпать - но костылить больше. А вот вручную браузить - уже геморрой и кривизна. Потому что если половина съемки в энной локации там, а половина в другой дире - ну, круто, конечно, да.
> Дядюшка ляо тоже разный, всякие плохие дороги - тоже ляо.ну видимо, так и есть. В конце-концов для плохой дороги это не основной бизнес, и вполне может вообще быть где-то в виде отдельно-стоящего сарая с совсем кончеными ляо.
> Стандарт стандартом, а фоты сортировать из этого барахла довольно неудобно. Потому что
> группируются по дирам по черт знает каким критериям.критерий банальный - последовательность создания. Может, чем фантазировать-то - взять да и прочитать описание стандарта? Принтер с прямой печатью - очень даже о нем знает, если что.
> Честно говоря я ни разу не видел кого-то использующего какие там еще принтеры сразу с фотика.
мало ли, чего ты еще не видел. Я вот видел бизнесы, построенные на этой технологии.
Суешь мобилу в разъем киоска - получаешь на руки пачку фоток (или qr-код со ссылкой на "облачко", чтоб денег не платить)> По дате, например, что самое логичное.
абсолютно алогичное. Вон пачка "собачка с дачки". Фотка сделанная первого мая, фотка сделанная пятого мая - да какая нахрен разница - какого мая? А вот между ними лежат timelapse, парочка по 200 штук.
И поскольку идея "подождать, пока оно нагенерит превьюшек для всех этих мегапикселей" даже при таком (небольшом, сравнительно) количестве выглядит не очень привлекательно - единственным разумным и недорогим в реализации выглядит вариант просто пихать в разные каталоги примерно поровну - в количестве, позволяющем как-то визуально отделить мух от котлет, а не на датах гадать. Разобрал одну свалку - разборку второй отложил на попозже. Вот и вся возможная "оптимизация".
А если вместо этого одна общая куча на сороктыщ фоточек (или еще хуже - видеороликов, которые не всегда удается однозначно идентифицировать даже по графической превьюшке) - то костылить ты будешь, внезапно - ее обратный попил на кучки поменьше, которые ты в силах обработать за обеденный перерыв.Поэтому ничего и не меняется двадцать лет, а не потому что fs де не позволяет.
> сарая с совсем кончеными ляо.Ляо вообще не то чтобы великие софтоклепатели. Но пипл хавает же.
> да и прочитать описание стандарта?
Я не собираюсь это имплементить -> не вижу повода засорять мозг. К тому же стандарты разные бывают. Иди вон почитай стандарт на мсовский OOXML. Всего 6000 страниц мусора пытающегося описать то что делал их эксель :). Вообще, идея конечно крутая - сперва такого монстра родить, а потом задним числом формальные спеки на него пытаться изобразить.
> Принтер с прямой печатью - очень даже о нем знает, если что.
Да пох мне на твой принтер, честно-честно. Меня гораздо больше напрягает что половина фотосессии в одной дире а половина - в другой. Это неудобно.
> мало ли, чего ты еще не видел. Я вот видел бизнесы, построенные на этой технологии.
Да я допускаю что это даже где-то бывает. Но в целом это довольно маргинальное нечто.
> Суешь мобилу в разъем киоска - получаешь на руки пачку фоток
И троянца от NSA в подарок? :) А то хомяки стали прошареные, даже от остановок заряжаться и то ссутся уже.
> (или qr-код со ссылкой на "облачко", чтоб денег не платить)
А в чем пойнт? Любой хомяк может и сам в облако свою фотку залить. Без извратов с разъемами и QR кодами.
> абсолютно алогичное. Вон пачка "собачка с дачки". Фотка сделанная первого мая, фотка
> сделанная пятого мая - да какая нахрен разница - какого мая?Ну как бы 1 и 5 мая не сильно далеко. А вот если собаке устроить фотосессию - не прикольно когда половина в одну диру, половина в другую. Потому что б-цкий девайс сам так видите ли решил. Это вымораживает даже обычных хомяков с гаджетами. Потому что какое-то техническое г#вно изволит им палки в колеса их затее пихать, в общем то, называя вещи своими именами. И приходится вручную это двигать за зело вумным гаденышом.
> А вот между ними лежат timelapse, парочка по 200 штук.А их заскипать не сильно сложно. В том числе автоматически/полуавтоматически, по датам как раз. И таки совсем не круто если оно на середине вдруг брык - и в другой дире.
> И поскольку идея "подождать, пока оно нагенерит превьюшек для всех этих мегапикселей"
> даже при таком (небольшом, сравнительно) количестве выглядит не очень привлекательно -...можно просто посмотреть на даты и заскипать это при разгребании карты :)
> - разборку второй отложил на попозже. Вот и вся возможная "оптимизация".
Называя вещи своими именами - проблемы техники и убогих ФС решили за счет пользователей. И таки обычно превьюшки там встроены в файлы, генерить их не надо. Правда стандарт на это толи отсутствует, толи недавно появился. Для равок в dng это точно было, а вот доползло ли счастье до жыпегов - не знаю.
> А если вместо этого одна общая куча на сороктыщ фоточек (или еще хуже - видеороликов,
Ты там что, энтерпрайзную хранилку с собой таскал? Или куда ты 40 000 роликов раскладывал? :)
Если кто не понял юзеры подорвались 9К фот разгребать потому что на их 128 гиговом нечто стало место кончаться, однако %)
> графической превьюшке) - то костылить ты будешь, внезапно - ее обратный
> попил на кучки поменьше, которые ты в силах обработать за обеденный перерыв.Я сделаю обратный попил по дате, попытавшись нащупать границы "сессий" - и поимею по крайней мере логически подобранные серии. Конечно это не поможет при желании сделать именно подборку "собака с дачи" но прокатит в многих других случаях.
Более того - меня может устроить и подборка "дача" где кроме собачек будут еще цветочки, поля, луга, старый хрыч на завалинке и проч. Хотя пойнт в некотором смысле валидный, MS когда-то что-то такое пытался в winfs - нечто типа тегов. Но - не зашло народу походу. В принципе в пингвине что-то сравнимое можно сделать симлинками, пожалуй, но опять же канительно "теги расставлять".
> Поэтому ничего и не меняется двадцать лет, а не потому что fs де не позволяет.
А таки хомяки на такую структуру дир матерятся и я считаю что у них есть пойнт.
Вот только фотоаппараты обычно сами организуют схему хранения фото на карточке. На примере самсунгов варианта как минимум два - либо хранени "в кучу" и на каждую тысячу фото создается новый каталог либо хранение по дате, на каждую дату по каталогу. Так что вероятность упереться в 65 тысч ну это как-то врядли, особенно учитывая что ресурс затвора тоже не вечен.
Ресурс затвора в нормальных камерах вполне себе переплёвывает эту скромную циферь. Какой-нибудь свадёбщик за сезон легко отснимет больше
угу, а потом продает в конце сезона эту камеру, с подписью "использовалась любителем, всего пара тысяч снимков". Лошье иногда покупает.
То, что удалена поддержка VFAT, это правильно. Потому что указывать NLS для exfat это какое-то извращение.Надеюсь что в sdfat пофикшена ситуация с правами на файлы. Что там нет такого, что удалить или создать файл ты можешь только от root, а потом вставляешь флешку в винду, а там "доступ к файлу запрещён".
Было такое с их предыдущим драйвером exfat 1.2.4 на ядре 3.11.
И да. Самое главное забыл сказать. Самсунгу спасибо. Хорошая работа. И за драйвер, и за включение в ядро. Теперь телевизоры и магнитолы будут поддерживать флешки с exfat
Через несколько лет. Когда это доберется до LTS, а потом до китайских лабораторий
> Теперь телевизорыДа давно уже. Разве что совсем какой-то дешман не умеет.
Улыбнул коментарий к патчу: https://lkml.org/lkml/2020/1/19/170Длы труЪ:
Патч:
> + /*
> + * GMT+-12 zones may have DST corrections so at least
> + * 13 hours difference is needed. Make the limit 24
> + * just in case someone invents something unusual.
> + */Коментарий:
> "13 hours difference is needed"
>
> This is not truth :-) Every traveller knows that Kiribati has only standard time and is in GMT+14 time zone.
>
> But limit ±24 is enough, at least for now.
Только ради флешек - неинтересно.(
> Драйвер переименован с sdfat в exfatДрайвер переименован ИЗ sdfat в exfat
Пиши верно!
все равно на флешках будет fat32/ntfs, а в андроид ext.
Сейчас флешки на кучу гигабайт. Даже в салонах связи уже USB 2.0 флешки на 16 Гб ушли в дальний угол, уступив место USB 3.0/3.1 флешкам на 128 Гб. Так что наверное их теперь форматируют в exFAT. Наверное. Я не знаю, у меня нет таких денег
если ты про те флэшки, которые thumb drive - их теперь (как и десять лет назад) форматируют в ntfs по преимуществу. А вот те что microsd - теперь поголовно exfat, потому что это прописали в стандарте xc.Переделывать скорее всего себе дороже, потому что встроенный wear leveling наверняка учитывает где лежит mfs в первом случае, и (единственная, хехе!) копия fat во втором.
> где лежит mfs в первом случае, и (единственная, хехе!) копия fatmft, fffuck...
> их теперь (как и десять лет назад) форматируют в ntfs по преимуществуДа вот не совсем правда. Если стоит задача таскать данные не только между виндами, то exfat даже 10 лет назад был лучшим - win + mac нативная поддержка, на линуксе хватало fuse. Плюс ntfs имел скорость записи ниже и обязательно требовал безопасного извлечения - бухгалтера постоянно теряли файлы на флешках, когда дёргали их из компа.
> Да вот не совсем правда. Если стоит задача таскать данные не только
> между виндами, то exfat даже 10 лет назад был лучшим -ну мне вот чего - флэшку из-за него переформатировать? Как kingston решил, так и будет лучше!
> win + mac нативная поддержка, на линуксе хватало fuse. Плюс ntfs
> имел скорость записи ниже и обязательно требовал безопасного извлечения - бухгалтераэто что-то странное. Обычно либо первое (на машине бухгалтера) либо второе (на моей, где винде сказано не включать "optimize for quick removal")
> постоянно теряли файлы на флешках, когда дёргали их из компа.
как будто если кэшируемый exfat дернуть на ходу, не потеряешь? (хотя, там наверняка в родной винде какая-нибудь антиоптимизация именно на этот случай, из серии саму fat/битмэпы не кэшировать в принципе)
> ну мне вот чего - флэшку из-за него переформатировать? Как kingston решил, так и будет лучше!Я ж не навязываю, а делюсь опытом. А кингстон действительно может знать больше нас. Тем более в наше время ресурс флеша очень велик и сегодня можно на флешке гонять что угодно.
> Обычно либо первое (на машине бухгалтера) либо второе (на моей, где винде сказано не включать "optimize for quick removal")
Бывал в конторе, где без чиха админа можно было только "пуск" открывать - приходилось бухам показывать куда что тыкать. Хорошо что винда им сама рассказывала, что так делать нельзя и они даже запомнили. Дома понятное дело подождать несколько секунд не смертельно и галочка была проставлена сразу при втыкании флехе.
> как будто если кэшируемый exfat дернуть на ходу, не потеряешь? (хотя, там наверняка в родной винде какая-нибудь антиоптимизация именно на этот случай, из серии саму fat/битмэпы не кэшировать в принципе)
Да, я тут слегка перепутал и почему-то подумал что так как минимум с 7 работало. С год назад в 10 поменяли для внешних накопителе по-умолчанию на "быстрое извлечение" - теперь можно вообще не париться на этот счёт.
> Тем более в наше время ресурс флеша очень велик и сегодня можно на флешке гонять что угодно.Угу, этак сотню циклов в TLC :). Фабричные ФС еще и раскладывают специфично - с выравниванием границ ФС на eraseblock и уж тем более на страницы.
Наивное переформатирование без учета этого может привести к тому что при неудачном сдергивании флехи/карты в страну вечной охоты однажды отправится таблица разделов. Потому что попала в тот же eraseblock что и обновляемые структуры и при слете питания не успело записаться назад.
Так что если хочется самому форматнуть то по крайней мере учесть размер страниц (4..8К или типа того) и eraseblock/erase group (несколько мегов, кратно 2^N, например, 4, 8, 16, .. ). Без этого можно однажды здорово обломаться. По той же причине не стоит форматить карты средствми виндов и даже девайсов без острой нужды.
> Угу, этак сотню циклов в TLC :)Это же не SSD, сотни циклов на десять лет может хватить. У меня на минифлешкe Sandisk 8 гиговой уже лет 5 стоит убунта на ext4 и загружается с неё. Конечно, там все кеши и логи на рамдиске, стоит relatime, однако флешка на удивление очень живучая (хотя я регулярно скидываю с неё дамп ddrescue). А в старом фотоаппарате стоит SD карта (ещё из настоящих, полноразмерная) ёмкостью в 256 мегабайт (как раз на заряд аккумулятора и 100 снимков) - до сих пор рабочая.
> Так что если хочется самому форматнуть то по крайней мере учесть размер страниц (4..8К или типа того)
На всех осях размер блока стоит минимум 4К. Недавно втыкал в винду свою 32-гиговую загрузочную - она предложила сделать размер 32К.
> eraseblock/erase group (несколько мегов, кратно 2^N, например, 4, 8, 16, .. )
Учитывая, что в той же винде это сделать несколько сложнее, чем ПКМ - Форматировать, я бы на это забил (почему - написал ниже).
> Без этого можно однажды здорово обломаться. По той же причине не стоит форматить карты средствми виндов и даже девайсов без острой нужды.
В любом случае, флешка - это временный носитель и её нельзя использовать как хранилище. Проще для тех же бухгалтеров купить мешок гиговых флешек и выдавать по надобности, чем учить их вот этому всему.
> Это же не SSD, сотни циклов на десять лет может хватить.Там еще контроллер паршивый и wear leveling делает абы как. И к тому же 100 циклов - это когда оно разбалтывается и начинает дико течь профакивая данные, или вообще не стирается. А так этот кал через несколько лет может перестать читаться сам по себе, например. Или если ты его задолбал чтениями. Потому что учитывать read disturbance тупой контроллер может и не уметь. Иногда требуется даже все шифровать. Не потому что спрятать что-то надо, просто большой паттерн нулей или единиц подряд влияет друг на друга и чтение сбоит еще раньше. Шифрование делает некую рандомизацию, проблема отпадает. Ну и чем новее и емче, тем мельче ячейки и тем быстрее они утекают. С соотв ожиданиями для сохранности данных.
В общем емкий флеш - очень хлипенькая и ненадежная штука. "Barely works".
Старые флешки юзают дубовый SLC или как максимум 2-level MLC. Первое почти вечное, второе ... зависит от отлаженности технологии и контроллера. В ранних он был не сильно лучше TLC сейчас, потом отладили и улучшили, конечно.
> фотоаппарате стоит SD карта (ещё из настоящих, полноразмерная) ёмкостью в 256
> мегабайт (как раз на заряд аккумулятора и 100 снимков) - до сих пор рабочая.А чего ей? SLC NAND иной раз до миллиона циклов выдерживает. Вот его хрен протрешь. Представляешь что такое миллион раз заполнить карту? Даже такую? :)
> На всех осях размер блока стоит минимум 4К. Недавно втыкал в винду
> свою 32-гиговую загрузочную - она предложила сделать размер 32К.Зато можно положить блоки неудачно, так что твои блоки попадут на пересечение физических блоков. И вот тебе надо записать 1 блок, а железка пойдет ворочать два, с дурацким RMW обоих. Скорость записи убьется в разы, износ возрастет в разы. Write amplification.
C eraseblock примерно те же соображения. Кроме того что там стирание и RMW большое и интрузивное и если питание гавкнется а там критичные структуры были, типа partition table - упс.
> Учитывая, что в той же винде это сделать несколько сложнее, чем ПКМ
> - Форматировать, я бы на это забил (почему - написал ниже).В винде это вообще вроде сделать нельзя штатными тулсами. В пингвине - можно попытаться, но насколько угадаешь - вопрос. В любом случае придется полюбить степени двойки и раскладывать все весьма специфично. Ну например первые 16 или 32 мега (точно, как степень двойки) - партишн и reserved (чтобы никто никогда не трогал этот erase block/group). Потом раздел на сколько там. Следя за тем чтобы блоки фс тоже удачно начинались. EXT-ам еще можно попытаться захинтить желаемый размер IO но можно и не угадать.
> В любом случае, флешка - это временный носитель и её нельзя использовать
> как хранилище. Проще для тех же бухгалтеров купить мешок гиговых флешек
> и выдавать по надобности, чем учить их вот этому всему.А вот гиговые флехи могут жить довольно долго, потому что SLC. Скорее им разъем оторвут или чего еще.
Я вот не уверен, что всё ещё можно купить флешки на SLC. Помню только единственную флешку, которая у меня умерла от использования - моя первая в резиновом корпусе и аж на 128 мегабайт попросту внутри сгнила (вода попала или в кармане отсырела). Была ли она SLC - возможно, в то время особо не было альтернатив. С тех пор ещё ни одна не померла, а уже лет 15 прошло.В любом случае, я со всем, перечисленным вами, согласен. Жаль, что большая часть телодвижений обычно не стоит усилий. Но в качестве знания "как делать правильно" - очень полезные советы.
>> их теперь (как и десять лет назад) форматируют в ntfs по преимуществу
> Да вот не совсем правда. Если стоит задача таскать данные не только
> между виндами, то exfat даже 10 лет назад был лучшим -
> win + mac нативная поддержка, на линуксе хватало fuse. Плюс ntfs
> имел скорость записи ниже и обязательно требовал безопасного извлечения - бухгалтера
> постоянно теряли файлы на флешках, когда дёргали их из компа.Нативная только с первого сервис-пака Вистоньки, ЕМНИП. Давеча на внешний USB-винт, отформатированный ещё когда-то давно в exFAT из-под Мака, записал восстановленные файлы с помирающей Windows 2003, а когда оную установил заново, то не смог из неё прочитать спасённое. И не сразу даже вспомнил, что без KB955704 она читать exFAT не умеет. Переволновался. Но потом таки вспомнил.
> Нативная только с первого сервис-пака Вистоньки, ЕМНИП.Ну Вистонька была намного раньше 10 лет назад. Даже Семёрочка уже старше )
> Windows 2003, а когда оную установил заново, то не смог из неё прочитать спасённое. И не сразу даже вспомнил, что без KB955704 она читать exFAT не умеет. Переволновался. Но потом таки вспомнил.В XP тоже завозили поддержку с каким-то патчем, так что не всё так плохо с поддержкой. До сих пор на винте валяются критичные патчи для разных виндов (типа апдейта инсталлера, ексфат и ещё несколько), когда не хочется ломать систему виндовс апдейтом, а функционал нужен. Даже дамп собственных дискет NT4 имеется.
>> Нативная только с первого сервис-пака Вистоньки, ЕМНИП.
> Ну Вистонька была намного раньше 10 лет назад. Даже Семёрочка уже старше
> )
>> Windows 2003, а когда оную установил заново, то не смог из неё прочитать спасённое. И не сразу даже вспомнил, что без KB955704 она читать exFAT не умеет. Переволновался. Но потом таки вспомнил.
> В XP тоже завозили поддержку с каким-то патчем, так что не всё
> так плохо с поддержкой.Для XP патч с тем же номером, что и для 2003-й. Для установки требуется обновление до SP2.
> До сих пор на винте валяются критичные
> патчи для разных виндов (типа апдейта инсталлера, ексфат и ещё несколько),
> когда не хочется ломать систему виндовс апдейтом, а функционал нужен. Даже
> дамп собственных дискет NT4 имеется.У меня не только валяются, но и активно используются (для XP и 2003). :)
Ну, картчоки от 64ГБ уже изначально в exFat отформатированы, ибо "стандарт". именно за это Микрософт всегда и пинали, что в стандарт прописали ФС на которую права не дают никому.
> именно за это Микрософт всегда и пинали, что в стандарт прописали
> ФС на которую права не дают никому.как будто это мы (одни) прописывали. Мы, если что, winmobile давно не производим, нам оно вообще нафиг не надо было.
> нам оно вообще нафиг не надо было.Так-так, а кто за патенты бабки стриг?!
Мда-а-а, 4ГБ... когда-то у меня жёсткий диск был 4ГБ... и всё влезало...
> Мда-а-а, 4ГБ... когда-то у меня жёсткий диск был 4ГБ... и всё влезало...везунчик. У меня были 2x40 мегабайт - ничерта не влезало.
Потом был 320 - все равно не влезало.
Потом, правда, ненадолго было щастье - у меня был jaz-drive, который вылезал, и заменялся новой "дискетой" гигабайтного объема (хотя держать там ценное и было немного стремно, учитывая конструкцию) - но в 98м слуцился какой-то там хризис, и дискеты перестали быть по карману, а потом и просто пропали из продажи (видимо, никто не покупал).
Теперь вот 12T raw disks в кластерах - ВСЕ РАВНО, БЛ... нихрена не лезет!
не занимался бы ты рукоблудством то и места всегда бы хватало
Ну так порноиндустрия тоже не стоит на месте. За эти годы мы прошли путь от 240p до 2160p.
Скоро можно будет взять флешку в магазине, и... десктопный линукс из коробки её распознает.
Так близко к захвату десктопов линукс никогда не был.
> Скоро можно будет взять флешку в магазине, и... десктопный линукс из коробки
> её распознает.а раньше он у тебя что - не распознавал? А, ну да, у тебя ж год линукса на десктопе, каждый год, да?
P.S. exfat-fuse существует десять лет, если не больше, и я хрен знает где ты находил такие десктопные линуксы, в которых он не в поставке.
> exfat-fuse существует десять лет, если не больше, и я хрен знает где ты находил такие десктопные линуксы, в которых он не в поставке.Да любой - не промахнёшься.
Самому поставить можно.
>> exfat-fuse существует десять лет, если не больше, и я хрен знает где ты находил такие десктопные линуксы, в которых он не в поставке.
> Да любой - не промахнёшься.
> Самому поставить можно.не, нельзя - надо ж сперва поставить сам линукс, а это практически невозможно, да еще ведь - десктопный!
Действительно, это ведь не то, что за винду платить или активаторы искать.
> Действительно, это ведь не то, что за винду платить или активаторы искать.где вы берете хлам, на котором "за винду надо платить" ?
Я вот когда-то покупал только что тогда появившийся asus eeepc700 - так доплачивать надо было за _linux_ версию (он поставлялся и так и так) - причем так солидненько, процентов 15 от цены (я, правда, хотел еще и розовенький, но черные с линухом стоили столько же)
А я в свое время таки сэкономил на версии с FreeDOS вместо винды. После чего честно вкатил туда пингвин.
я думаю, там вся экономия была из серии "эту истеричку проще удовлетворить чем объяснять что ничего так не сэкономит".
> я думаю, там вся экономия была из серии "эту истеричку проще удовлетворить
> чем объяснять что ничего так не сэкономит".Там экономия была около 2 кусков в одинаковой конфиге. Видимо по цене винды.
Это потому что в Линукс версии было больше дискового пространства (правда чуть медленнее)
> Это потому что в Линукс версии было больше дискового пространства (правда чуть
> медленнее)нет, 700-е были все одинаковые, 4g намертво распаянного ssd should be enough for all. Просто чорная windows версия (примета - перекосо$#@ный пробел) была завезена каким-то крупным ритейлом огромной партией, а вот цветные и неправильной ориентации - были чемоданных завозов всякой мелкой шушерой. Ну и вообще, логичненько - хочешь некаквсевости - это эксклюзив, оплата соответственная.
>> Это потому что в Линукс версии было больше дискового пространства (правда чуть
>> медленнее)
> нет, 700-е были все одинаковые, 4g намертво распаянного ssd should be enough
> for all. Просто чорная windows версия (примета - перекосо$#@ный пробел) была
> завезена каким-то крупным ритейлом огромной партией, а вот цветные и неправильной
> ориентации - были чемоданных завозов всякой мелкой шушерой. Ну и вообще,
> логичненько - хочешь некаквсевости - это эксклюзив, оплата соответственная.Я когда хотел купить 700-ый и "шукал" на эту тему меян продаван всячески отговаривал от Линук версии именно мотивируя это тем что "памяти больше но она тормозная". Хотя кто знает, давно это было.
Еще помнится Линукс там был странный, Ксандросс какой-то О_о, хотя все ставили крашбанг
Странно, сейчас наоборот практика такова, что без винды дешевле выходит покупка железяки. И обычно когда пишут всякие FreeDOS то там может впринципе не быть никакой операционной системы, у меня так и было лично.
Пусть будет Парагон :3
А у меня вопрос. Если бы Перегон не шевльнулся бы то Сосунг бы не "предложил новый вариант драйвера exFAT для ядра Linux"?
Если бы Майкрософт не пришел в себя то никто бы ничего не выложил.
так и пользовались бы по сей день старой версией самсунговского, вы хотите сказать? (хинт - ему сто лет)
Да той самой версией которая сбойные блоки не умеет читать. Когда родной мелкософтовский драйвер ту же карточку читает не спотыкаясь.
а ей точно надо уметь это делать? Может, все же, пора выбросить копеечную карточку, особенно, если содержимое хоть как-то дорого?
Может микрософту надо было сразу опенсорсные дрова делать, а не творить своё EEE как обычно? Раз карту можно прочитать хоть как-то с ней все в порядке.
раз с картой все в порядке, а линуксное ядро (не имеет никакого отношения к extfat) видит сбойные блоки - вам надо просить microsoft об опенсорсных дровах usb, или через что у вас там.Могли бы, конечно, и сделать - но зачем им?
P.S. у меня есть прекрасная машина, дающая множественные dma error на обращениях к sata. В линуксе. В винде - "просто работает", ага. ich9.
>винде - "просто работает", ага. ich9.Есть до хрена машин где этот DMA вылазит в винде.Лечиться либо внешним контроллером или если производитель позаботился новой прошивкой.Вам повезло, в драйверах под винду иметься исправленная фимварь.Иногда ошибок нет,но винда регулярно слитает через пару недель....так что не все с этим чипом в порядке.
> Если бы Майкрософт не пришел в себя то никто бы ничего не
> выложил.Может на то были причины. Кто его знает, может в следующей специфиации SD пригрозили F2FS сделать стандартом.
> Если бы Перегон не шевльнулся бы то Сосунг бы не "предложил новый вариант драйвера exFAT для ядра Linux"?Сначала в Staging ядра влили exfat-nofuse. Немного слов об этом драйвере. Он базируется на драйвере exfat, разработанном Samsung для устройств на базе Android. В драйвере exfat-nofuse есть изменения, внесённые сообществом открытого ПО (я не знаю, насколько их много). Также производится синхронизация с апстримом: на сайте Самсунга можно скачать исходные коды прошивок (например в прошивке для устройства Galaxy S7 есть самый новый драйвер).
Потом Microsoft разрешила использовать exfat. Потом exfat-nofuse добавили в Staging. Потом кто-то сказал "но ведь в прошивках для Galaxy S8 и новее, уже нет exfat - вместо него sdfat, то же самое, только лучше".
Потом Paragon представил свой драйвер, который на начальном этапе поддерживал "только чтение". Возникла вероятность, что в ядро примут драйвер Paragon, а не Samsung, потому что Paragon будет заниматься поддержкой своего кода, а драйвер Samsung поддерживают только энтузиасты, чиня сборку на новых ядрах, и периодически синхронизируя с апстримом.
Шевельнулся бы Самсунг, если бы не Парагон? Я думаю, что да. Но велика вероятность, что ты прав
Лучше бы они zfs добавили.
извините, мы не можем пока найти ей применение в своем телевизоре!
Так и так три драйвера, и все даже в репах есть. В чем проблемы с ZFS? Ну c fuse понятно. Но с родным какие проблемы?(Это не риторический вопрос, хочу на бук поставить основной FS)
Ну и отвалится он с каким-нибудь новым ядром после очередного выкидона Линуса и посмотрим что ты будешь делать ну или мейнтенер твоего дистрибутива.
то же самое, что если отвалится драйвер нвидии или тачпада (что гораздо более вероятно), а то и вообще fcoe карты, как вон редгад придумала - откатится на предыдущее, и больше апгрейдиться не будет.
Одно дело что у тебя видюха обратно свалилась на опенсорсные дрова и показывает 1024x768 другое когда у тебя фс отвалилась, а то и развалилась до неконсистентности.
ну это если что показывает, а не чорный экран из-за багнутого 6ешплатного kms-драйвера, как у меня бывалоча.А если рутовый раздел отвалился, "потому что ваш устаревший и немодный pci-id выпилен из .h файла драйвера, при том что в самом драйвере ничего не менялось"(c)redhat ?
Ну и пока - авторы zol в этом плане молодцы, не смотря на все намеренно создаваемые им линукс-диверсантами проблемы - поддерживают чудовищный спектр ядер аж начиная с 2.6, и заканчивая самыми распоследними (которые лично на меня внезапно не напрыгнут, я не рач с распоследних исходников каждый день собираю же)
А вот модный самсуньский драйвер у меня, увы, не соберется - придется жить с немодным. Поскольку процессор медленный и расставаться с неправильным проклятым проприетарным vaa я не планирую.
> ну это если что показывает, а не чорный экран из-за багнутого 6ешплатного
> kms-драйвера, как у меня бывалоча.Ага, а знаешь почему я народу их семерку на пингвин сменил? Потому что для их старинной нвидии для семеры драйверов нету, бжад. А как стандартный VGA оно с такой скоростью рисует, что даже 360p на ютубе - адское слайдшоу.
А вот нуво на удивление подцепило эти костяшки. В логи пиндит какими-то ошибками, но рисует со скоростью ракеты, а больше от него ничего и не надо.
> то же самое, что если отвалится драйвер нвидииНу так кто завязался на блоб - знал на что шел.
> или тачпада (что гораздо более вероятно),
Ни разу не видел дров точпада блобами. И таки у меня ничего не отваливалось.
> и больше апгрейдиться не будет.
А на этого господина время обиделось. И теперь у него всегда полшестого и всегда пора пить чай.
> Поддержка файловой системы exFAT появилась в Windows Vista Service Pack 1 и Windows XP с Service Pack 2.Уточняем: для XP нужно вручную ставить KB955704, а вот для него и нужен SP2.
> максимальный размер раздела в 32 ГБОткуда люди взяли такое ограничение?
Почему до сих пор считают кластера по 512 байт?
Сейчас даже на современных дисках сектора по 4 кб (см. Advanced Format)
Целесообразно выбирать размер кластера равным размеру сектора (или больше).
В таком случае раздел FAT32 - будет больше 32Гб (как я и жил на windows 98 с HDD 250 Гб)