Микулаш Патокка (Mikulas Patocka), один из разработчиков LVM и автор ряда изобретений, связанных с оптимизацией работы систем хранения, работающий в компании Red Hat, представил в списке рассылки разработчиков ядра Linux новую файловую систему NVFS, нацеленную на создание компактной и быстрой ФС для чипов энергонезависимой памяти (NVM, non-volatile memory, например NVDIMM), сочетающих производительность ОЗУ с возможностью постоянного хранения содержимого...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53743
>не принятой в состав ядра Linux из-за своей усложнённостиПфф, ещо чего не хватало! Не дай Бог ламповые глюки ядра обойдут, а без них Linux не Linux.
Не вы ямы копали — не вам их и закапывать.
Ну как бы сложные ReFS и BTRFS так и не вышли из стадии игрушек.
Facebook использует Btrfs по полной программe плюс коммитит в ядро, но типический ваня сидящий на диване в мухосранскe вещает: нет, это игрушка!
да некоторые и петабайтные кластеры на refs уже понасобирали (нет, не знаю, зачем - возможно, просто редбиэму платить не хотят, а ms уже заплачено сполна) - и комитить в ведро им незачем при этом.
Фэйсбук может хоть фат12 использовать, там армия спецов есть и многа денег на это, а то что бтрфс глюкоташная рулетка факт, о котором знает и Линус и Ваня и редхат, тока тебя и фейсбук не умедомили.
> бтрфс глюкоташная рулетка факт, о котором знает и Линус и Ваня и редхати именно поэтому редхат внедряет бтрфс по дефолту в федоре??? ЛОЛ, у тебя логика порвалась.
> хоть фат12 использовать, там армия спецов есть и многа денег на это
фейсбук коммитит открытый код в ядро ВНИЗАПНО, весь код открыт, проверить слабо ибо чукчa не читатель? либо в криокамере застрял?
Именно поэтому. Была бы не игрушкой - была бы в RHEL. А пользователи федоры - официально подопытные кролики.
Но она по дефолту в SUSE
>и именно поэтому редхат внедряет бтрфс по дефолту в федоре???ну а на ком тестировать, на тех кто деньги заплатил?
btrfs они объявили deprecated и стали развивать другие. А сейчас прошло несколько лет, почему бы не потыкать палочкой? Вдруг фейсбук таки сделал чудо
> весь код открыт, проверить слабоПроверенно, месяца три назад, на только что отформатированный диск слил гигов 500, выдернул и все, ни данных ни фс.
> бтрфс по дефолту в федоре
Че там в федоре хз, но из редхата это действительно удалили, так что кого с разморозкой еще вопрос
Смешные вы. Мало ли что использует фейсбук. Давайте теперь на пахе писать тогда
Подрывом пуканов - удовлетворен!P.S. а вообще брали бы пример с г-на Комарова - смотрите, смотрите - уже в шестой раз с поклонами переподает. Еще пара лет - и в ведре (помойном, потому что затрахает же ж переподавать и его).
Правда, директорская зарплата хотя бы позволяет ему все это время жевать хлеб с маслом, а не хер без соли...
Ссылочку дайте.
Subscribe by sending subscribe linux-fsdevel in the message body to majordomo@vger.kernel.orgКаких тебе еще ссылочек, смузихлеб опоздавший родиться? Правильные пацаны вот так с кодом работают! (а что там два патча из десяти теряет древняя кривая софтина из времен, когда компьютеры были большие, так это похрен, перепошлют)
Что-то ты часто укоряешь других в поздем рождении. А сам-то ты в каком веке родился?
Нехватает пожатия на лету в lz4.
для таких хранилок лучше сжимать в zstd, ибо распаковка не будет замедлена (но места станет больше).
Zstd топчик, на сильном сжатии он даже может обходить lzma без вопросов, но всё ещё быстрее. А главное распаковка быстрая -- у lzma распаковка адово тормозная, хуже lzma только bz2.
процитирую себя===========
мобильный ryzen 5 2500zstd --ultra -22 = 16 сек, xz -9 = 12 сек. при этом xz пожал лучше. один файл, конечно, не показатель
zstd -9 1.4 сек, итоговый файл 10.4 мб. gzip -9 - 6.6 сек, итоговый файл 11.1 мб
=========вообще, на чём я пробовал, zstd --ultra был медленнее xz, и жал хуже
Ну такое, да. В прошлый раз, zstd был быстрее (разница доходила до 15%), и файлы меньше выдавал (примерно на 0.5%), но там другие, менее скучные датасеты были. Равноценно, в принципе. Зато распаковка быстрее.===
префикс вайна
===
zstd-22:.wine-64
real 4m24.891s
user 10m11.530s
sys 0m7.929s
-rw-r--r-- 1 anon anon 416M Sep 19 01:10 winedrive.tzst
xz-9:.wine-64
real 4m12.598s
user 13m13.847s
sys 0m6.941s
-rw-r--r-- 1 anon anon 413M Sep 19 01:20 winedrive.txz
===
пара текстовых файлов
===
zstd-22:txtdata
real 1m31.187s
user 1m30.307s
sys 0m0.657s
-rw-r--r-- 1 anon anon 23356543 Sep 19 01:28 txtdata.tzst
xz-9:txtdata
real 1m32.539s
user 1m32.019s
sys 0m0.483s
-rw-r--r-- 1 anon anon 23125096 Sep 19 01:26 txtdata.txz
Распаковка в… Ну у меня получилось в 5 раз быстрее, но вообще там очень медленно и тут просто мелких файлов много наверно, 0.3с сложно с 1.5с сравнивать.
zstd никогда не был быстрее lzma2, а уж тем более непрерывного архива rar5.zstd быстр на распаковке ценой меньшей степени сжатия за короткое время.
не нужно при помощи него сжимать данные на хранение! для этих целей есть rar5.
Вы видимо анонимный эксперт, вам скорость или время?
вы видимо админ локалхоста, попробуй сохрани в облаке пожатый архив размером в 100ТБ, посчитай сколько бабла тебе это встанет, и поймеш зачем нужен РАР5.
а оно в мультипоточность умеет, или такое же как и gzip, однопоточное гв-но? даже pigz легко обходит тот-же gzip ровно в Х-раз, где Х это количество доступных ядер.
> а оно в мультипоточность умеет, или такое же как и gzip, однопоточное
> гв-но? даже pigz легко обходит тот-же gzip ровно в Х-раз, где Х это количество доступных ядер.
>> Сжатие и распаковка блока ФС в ядре
>> мультипоточность
>> pigzА гонору-то, гонору сколько было *рукалицо*
pigz и lbzip2/pbzip2 должно быть тоже быстро
1. У zstd упаковка адово тормозная на высоком сжатии.
2. Степень сжатия сильно зависит от datasetа и от способа применения. У меня в black-box сценарии lzma2 пожал лучше, чем zstd, оба на максималках, а лучше обоих пожал ... brotli.
Как насчет потребление ресурсов ЦПУ в многопотоке на SSD/NVMe I/O?
В EXT4 не смогли вкатить. Подозреваю с NVFS ситуация будет аналогична.
Куда его там вкатывать и зачем? По принципу по-файлового шифрования? Я думаю, можно реализовать похожим образом. Нужно ли?
там где-то катается vdo, со сжатием и дедупликацией
Если кратко: очень медленно.
я и не говорил, что быстро, да и есть/было не везде. Зато не зависит от ФСподождем еще сколько-то лет :)
Жать данные с побайтовой спецыфикой доступа так же умно как хранение последнего рулона туалетной бумаги в правой холошне щерстяных штанов, которые внутри 2х пакетов разного цвета, которые в дальнем левом угле нижнего ящика, который внутри огромного шкафа, перед которым стоит стул и на котором спит кот.
> Жать данные с побайтовой спецыфикой доступастильно, модно и молодежно! Ведь "так в винде"!
(а что платить при этом за nvmem ценник, как будто она из цельного брильянта выточена, а не из обычного песка, как всегда, не имело никакого смысла - индусам похрен, насяльника павелела, джамшут капай!)
Эк, тебя понесло, уже индусов с ближним зарубежьем путаешь ;)
> NVM-память обеспечивает доступ на уровне отдельных байтовА может не надо лапшу на уши вешать?
Прояви гибкость и широту мышдения. Абстрагируйся от подробностей работы flash-памяти, они сковывают твой разум. Если ты будешь постоянно напоминать себе, что flash-память перед записью стирается блоками, ты не сможешь проникнуться осознанием необыкновенных преимуществ NVM перед HDD и проявишь неуважение к усилиям маркетологов самых крупных чипмейкеров планеты. И вообще, совать нос под капот в современном IT-мире - неприлично.
А при чём тут флеш?
> А при чём тут флеш?Хмм... действительно. Казалось бы, при чём он здесь?
Ты свой нос в наш бизнес не суй, плз, спс
> Ты свой нос в наш бизнес не суй, плз, спсТы мне не указывай куда нос совать или не совать, плз, спс.
Ну есть же Optane
Речь не про M.2 NVMe, а про nvdimm. Это обычные плашки оперативной памяти с возможностью сохранения содержимого DDR на flash при неожиданном отключении питания. Хотя они конечно наврали, поскольку оперативка тоже читается блоками больше одного байта.
угу, возможность сохранения же обеспечивается прямым подключением в ноосферу, а не тем что это тот же самый флэш, только без диско-эмулирующего интерфейса.Читается, насколько я понимаю, хоть побайтно. Пишется как обычно - страницами. Еще один, кстати, повод, не страдать херней со сжатием.
Там батейка стоит и её хватает, чтобы сохранить всю RAM в flash при внезапном отключении питания. А в обычной ситуации в flash запись не происходит никогда.
sure?
Потому что в верченных мной в руках модулях как-то не очень видно было место для батареек и отдельного flash размером с весь модуль, плюс собственный процессор, поскольку кто-то же должен производить всю эту интересную процедуру, да еще и восстанавливать обратно при включении питания. Не то чтобы не могли, конечно, хитро спрятать, но не проще ли ларчик открывается?
шуре.Только там не батарейки, а ионисторы. Отдельный флэш размером с весь модуль не нужен, т.к. можно использовать эти, как их MLC, V-NAND и прочее.
> плюс собственный процессор
там же не core-i9, контроллер может быть на том же кристалле, что и флеш
Ну вы в поисковике наберите nvdimm, там ж всё налицо, и флэш, и блок конденсаторов, который подключается через отдельный разъём. А если вам кто-то дал подержать в руках "nvdimm", а отличия от обычного вы не увидели - так может вам в уши этот кто-то нассал, что это nvdimm, а не обычный модуль оперативки?
>Читается, насколько я понимаю, хоть побайтно. Пишется как обычно - страницами.На уровне железа все пишется блоками в 64 байта (cache line, ага).
>Читается, насколько я понимаю, хоть побайтно. Пишется как обычно - страницами.На уровне железа все пишется и читается блоками в 64 байта (cache line, ага).
> Речь не про M.2 NVMe, а про nvdimm. Это обычные плашки оперативной
> памятиТак вот в обычную память процессоры, имеющие кеш-память, и не пишет по байту. Пишут и читают линейками.
Тем не менее, интерфейс позволяет читать и писать по одному байту.
Ребят, у них количество айнодов в фс задаётся при форматировании:> -N inodes - the number of inodes (by default, there is one
> inode for 20480 bytes)2020 год не перестаёт удивлять
Нет нормальных алгоритмов, все файловые системы это помойка. Btree тоже на свалку!
Не помойка, а база данных.
https://blocksandfiles.com/2019/09/05/samsungs-potentially-g.../
https://github.com/OpenMPDK/uNVMe
Ну ext4 как-то живёт, какие проблемы? Хм, сейчас посмотрел, на забитом диске 1% используется. Нда, с запасом отсыпает. На корне с хомяком 10% использовано.
Не скелиться если в одной папке много файлов, оно их физически выделяет в ОЗУ
Используйте ZFS, кому нужны эти ретроградские ext4 и xfs.
Лучше ext4, чем сын бсдшник.
Нынче в бздю кладут реализацию с zfs on linux, а не то, что было ранее.
Так что даже если использовать zfs - не факт, что будет бздишник.
Не сифилитик, а филателист, не бсдшник, а бдсмщик. bsd-версия zfs нимодна, нималадежна и уже выпиливают.
А "разработчики" из дельфикса уже пришли к вам, с огромным чемоданом садо-мазо инвентаря.
"Лучше пи́дор на рее, чем акула в трюме". ©2 капитана-2.
а почему не HAMMER2? Серьёзно. Жду развёрнутого ответа.
Серьёзно?!
Здесь ждешь?
ECC RAM и материнку для неё и камень серверный уже купил?
Других просто нету в стойках кроме ECC
Опять этот миф про необходимость ECC-памяти...
Тебе скриншотик этого "мифа" из консоли показать? (Да, внезапно, энтерпрайзные железки не только исправляют ошибки, но и внятно намекают, что раз исправил, два исправил - и хватит, давайте на всякий случай поменяем этот димм нахрен)Понятное дело, тебе, васян, не надо - если и перевернулся битик в твоем проне с лолями, ты никак этого не заметишь. Но, боюсь, ты расстроишься, если битик вот так перевернется в транзакции с твоей зарплатой (причем - знаковый, и ты ее всю банку вдруг должен). Начнешь же визжать, требовать сатисfuckций и гору золота за моральный ущерб - нет бы вздохнуть, сказать "ну че, бывает, зато компьютеры нынче дешовенькие", и денег банке отдать, как честный человек.
ЕСС является желательной и в это плане zfs ничем не отличается от других файловых систем. При ее отсутствии работать она будет нехуже других. "Перевернутый битик" это проблема памяти, а не файловой системы. Завязывание с веществами - читать противно!
Действительно, ведь бд сейчас обрабатывают данные сразу в фс без промежуточной загрузки в ОП. А ОП нужна только ОС...
А, ну в этом плане - да, не то чтоб сильно.
Но таки отличается в том моменте, что у этих "других" скорее всего все поправит fsck. С потерями поврежденных файлов (или сразу каталога, если прилетело не в файл - ну, зато файлы найдутся в lost+found, целенькие, только без имен), но без фатальных последствий.А у тебя "unable to import zpool" или повисший scrub, а то и вовсе kernel panic notabug. Не просто так документация фринаса ну ооочень настоятельно рекомендует. У этих ребят есть статистика (но, разумеется, она не для вас).
Впрочем, посмотри на кластерную moose - и посмейся. Ага, ВСЯ метаинформация в оперативе _всегда_ (то есть с максимальными шансами поиметь bit flip) - и при этом "а от контроля целостности мы отказались, потомушта тормозило [отдельный вопрос - КАК вы этого, блжад, добились на своем пентиуме 72?]"
И ничего, люди в этой фигне петабайты без бэкапа хранят.
Проблема была бы, если бы это количество нельзя было потом изменить.
Переформатированием?
>Ребят, у них количество айнодов в фс задаётся при форматировании:Я, когда увидел эту фразу: "Aрхитектура NVFS близка к ФС Ext4", тоже об этом подумал.
А сравнения btrfs где? И с ntfs
до кучи
btrfs труп, а ntfs онли винда, какие еще сравнения?
> btrfs трупОткуда у вас такая информация?
Мое знакомство с ней закончилось после того, когда каждый запуск виндовой виртуалки заканчивалось записью 2гб на ссд. Уж не знаю что с ней не так, но zfs пишет лишь сотню мегабайт при размере записи в 64к. Обе тестировались с компрессией.
Поздравляю со встречей с write amplification.Хотя и странно, почему с zfs она у тебя настолько мала.
Проблема ведь не в том, что WA имеет место быть. Проблем WA в непонятно каком месте и образом. Btrfs с компрессией записывает блоками по 128кб, а следовательно при сравнении с zfs с записью размером в 64кб WA должно быть ровно в 2 раза выше, но по факту - на порядок выше. И это просто запуск виртуалки с виндой и завершение ее работы, и больше ничего.
> Проблема ведь не в том, что WA имеет место быть. Проблем WA в непонятно каком месте и образом.да в целом-то понятно, непонятно что с этим делать теперь.
> а следовательно при сравнении с zfs с записью размером в 64кб WA
АААА! Вот где тебя кидают, надо было мне сразу сообразить. У тебя ж zfs тоже с компрессией и compressed arc до кучи, ты ж не отключал ничего руками? Ну так вот и поздравляю: при этом используется _переменный_ recordsize, а те твои 64 - это ограничение сверху.
Ошибаетесь, хотя при включенной компрессии действительно включается переменный размер записи, но так как образ - это один большой файл, то и пишется от максимальным размером. Файл 256М в уже упакованном виде при размере записи в 1М будет иметь 256 блока и любое изменение даже одного бай приведет к полной перезаписи этого 1М блока . О переменном размере блока речи уже не идет - файл размером с запись или выше уже записывается блоком максимального размера.
> в уже упакованном виде при размере записи в 1М будет иметь 256 блокаТам размер записи 64k, во-первых, и нет, там все блоки переменной длины, не только у коротких файлов.
Подумайте что происходит при попытке записи в середину пакованного файла из одних нулей килобайта из /dev/random. И наоборот. Собственно, именно из-за этого и пришлось вводить блоки переменной длинны, а не ради возможности сэкономить три копейки на сверхкоротких файлах.А вот btrfs, по всей видимости, может в этом случае только из одного блока сделать два, ибо нивлызло. Записали мы килобайт, на диск записалось 2x128, вот это красота, 256x write amplification на ровном месте.
(все, естественно, чисто умозрительно, я не знаю как она на самом деле устроена. Но имеющиеся чудеса объявняет довольно правдоподобно. Кстати, легко проверяемо автором.)
Файл с блоками в 1М был лишь примером. Каким будет оптимальным размер блока для одного большого файла? Разумеется максимальный. Вот откуда возникается WA и почему для образов виртуальных машин рек.размер записи как можно ближе к 4К.
> Файл с блоками в 1М был лишь примером. Каким будет оптимальным размер блока для одного большого
> файла?_до_ первой мелкой (!) операции записи в середину этого файла. Что и есть основной процесс, происходящий когда этот файл - виртуальный диск. После чего с переменным размером блока мы перезапишем пострадавший блок и небольшой непоместившийся туда хвост отдельным мелким блоком (для простоты опустим чего и сколько помимо того придется писать), а с постоянным - два блока полного размера 128k, второй из которых при этом будет почти пустым, но еще и при чтении будет нам префетч загаживать ненужными нулями.
> для образов виртуальных машин рек.размер записи как можно ближе к 4К.
видимо, для btrfs это действительно лучший выбор. И еще хорошо бы внутри vm попасть границами разделов на эти 4k, а не мимо. cow, кстати, как какие-то дятлы насоветовали, выключать не надо, совсем.
Да что я. Вы можете в этом убедиться с помощью утилиты zdb!
У BTRFS на большие файлы со случайным доступом на запись (базы данных и образы виртуалок) надо ставить атрибут nodatacow, как раз, чтобы твоей проблемы не было. Если бы ты хоть чуть-чуть ознакомился с документацией на ФС, которой пользуешься - у тебя бы не возникло таких вопросов.BTRFS по дефолту делает copy-on-write, поэтому на мелкие записи он не пишет в тот же блок, а создаёт новый модифицированный и меняет поинтер. Отсюда write amplification. Очевидно, это не желательно на образах ВМок, поэтому можно попросить ФС писать данные in-place. Во всех гайдах по BTRFS есть инфа, что на образы виртуалок надо ставить nodatacow.
Даже не знаю как это комментировать. Прежде чем что-то написать - вы бы потрудились вникнуть в прочитанное. Неловкая ситуация получилась.
Если человек не хочет, чтобы у него была активная запись на BTRFS по причине copy-on-write может этот самый copy-on-write отключить для файлика, где это вызывает у него проблемы. Если человек не хочет отключать copy-on-write для этого файлика, но при этом ноет, что ФС плохая - то у меня для него плохие новости - это уже забагованность его генетического кода.БД и виртуальные диски слишком большие и у них слишком случайные паттерны доступа, поэтому они плохо вписываются в механизм работы CoW. И не так сложно сделать `chattr +C` и отключить CoW на пару-тройку файлов, где это реально мешает (а пользы от CoW в целом так-то больше, если, конечно, на томе лежат не только имиджи виртуалок). Это не проблема файловой системы. Просто нужно знать сильные и слабые стороны ФС, с которой работаешь. Тем более, что ФС умеет хорошо работать с нагрузками такого типа, нужно просто дёрнуть за нужную ручку. Если это слишком сложно - то да, таким людям лучше просто не пользоваться BTRFS, т.к. это слишком сложная ФС, которая находится за гранью их интеллектуальных способностей.
Если же у вас только образы виртуалок на BTRFS лежат - то это ещё более странная претензия к ФС. Ибо для вас и микроскоп будет слишком плохим молотком. Каждой задаче - свой инструмент. И либо отводите какой-нибудь ext4/XFS под виртуалки, либо проставляйте правильно атрибуты на BTRFS.
Вам бы к врачу обратиться.
Не читаете доки вы, а обратиться ко врачу надо мне?
У вас проблемы с пониманием прочитанного. Все что могу предложить ещё раз прочитать и попытаться вникнуть в суть или обратиться к врачу.
Вас не смущает что самый распространенный формат дисков виртуалок qCOW2? И он сделает то же самое, только уровнем выше. Его тоже отключать?
Имхо главное чтобы COW не работал дважды, а где его отключать не так важно.
Но я бы конечно на уровне настройки приложения отключал (и отключаю), тоесть у qcow2.
Нет, не смущает. В QCOW2 CoW используется только при наличии снапшотов образов. Если вы не пользуетесь снапшотами ВМок - то у вас и так нет copy-on-write в образах ВМки. Запись в QCOW2 идёт in-place, а CoW происходит исключительно если у вас есть read-only снапшот и гипервизор пытается записать в read-only блок. При этом исходный блок копируется и копия становится read/write. Если вы "отключаете" CoW в QCOW2 - значит вы снапшотами не пользуетесь и всё равно у вас бы не было CoW на уровне приложения.В случае с BTRFS по умолчанию всегда происходит copy-on-write блока, вне зависимости от того, есть ли снапшоты у данного файла или нет. Это by-design заложено в архитектуре ФС. Я не предлагаю отключать глобально на всей ФС CoW, это действительно плохо (хотя и можно), но вполне можно помочь файловой системе и себе и поставить атрибут +C на имиджи виртуалок.
> Если человек не хочет, чтобы у него была активная запись на BTRFS по причине copy-on-writeто ему надо наконец перестать в голову есть и включить мозг - как именно copy-on-write может вызвать 256x write amplification. И быстренько сообразить, что он тут не то что не причем, а еще и вполне может улучшить жизнь если на fs включена компрессия. "На старое место" у вас _все_равно_ не влезет.
> Каждой задаче - свой инструмент.
а btrfs инструмент ни для какой задачи, так и запишем.
> И либо отводите какой-нибудь ext4/XFS под виртуалки, либо
просто не пользуйтесь недоделком.
У человека с zfs нет никакой проблемы, при том что там, о ужас, ужас - страшный _неотключаемый_ CoW.
А если еще он и zvol осилит, вместо бессмысленных для этой цели файлов...
Dataset вместо zvol был выбран вполне сознательно. Разумеется были проведены все необходимые тесты и dataset победил с завидным отрывом.
А в чем именно заключались тесты и в чем 'отрыв'-то?И что лежит на fs - qemu'овский qcow2 ?
Вполне может быть. Как раз если очередь записи неглубокая - страницы в page cache не задерживаются, и на каждые пару байт записи коммитится целый блок, который сразу же пишется на диск. И в итоге, вместо одной записи блока будут десятки CoW записей. Тут, конечно, проблема комплексная, надо разбираться, явно где-то кэширование неправильно работает. В госте, в гипервизоре или на хосте.Я не говорил, что CoW тут единственная проблема, но отключение его для образов виртуалки должно было существенно уменьшить write amplification. А дальше нужно уже искать, где у вас корявые кэши.
А пацаны из пейсбука и не знали.
Юзкейс пацанов из Фейсбука навряд ли совпадает с типовым.
Ну и чем оно лучше bcachefs?
NVFS = NTFSУ меня какие-то нездоровые аналогии. РеДГад является тайным поклонником Майкрософта?
> но не поддерживает снапшоты.так а зачем оно тогда вообще нужно? Бред же, ну.
> так а зачем оно тогда вообще нужно?ну вдруг тебе этих данных не так чтоб и жалко?
> Бред же, ну.
тебе ж сказали - скопипащено с ext4, потому что других идей в пропитанных карри головах не было.
Нет бы с fat скопипастить, хотя бы работало бы побыстрее...
>> так а зачем оно тогда вообще нужно?
> ну вдруг тебе этих данных не так чтоб и жалко?
>> Бред же, ну.
> тебе ж сказали - скопипащено с ext4, потому что других идей в
> пропитанных карри головах не было.
> Нет бы с fat скопипастить, хотя бы работало бы побыстрее...Ну да, FAT-то снапшоты поддерживает с первой версии.
Да, давайте для каждого типа памяти наплодим кучу своих ФС, а затем забьем на них болт и оставим без сопровождения для того чтобы придумать еще одну ФС
> Да, давайте для каждого типа памяти наплодим кучу своих ФС, а затем
> забьем на них болт и оставим без сопровождения для того чтобы
> придумать еще одну ФСТы ухватил самую суть современных создателей ФС.
Ну сюрприз - под байтовую адресацию нынешние ФС никто не делал. Ты ж tar не пытаешься как фс на дисках использовать.
пользователи mc недоумевают, почему?
Прекрасно ж работает.Только вот к произвольной записи немного плохо пригодна.
Линуксоиды, сэр.
Исправьте название в канале, а то позор ведь)
Покойся с миром старая шляпа.
Ещё одна ФС :( В ядре уже > 20 FS, лучше бы улучшали старые FS!!!
(существует 15 форматов)
- Надо сделать универсальный!
(существует 16 форматов)
Надо просто ненужное старьё повыкидывать, вроде ReiserFS и JFS
Я использую ReiserFS из-за её умения экономно хранить мелкие файлы.
Перестань её использовать
Сегодня суббота. В линуксе есть ФС, позволяющая эффективно использовать субботу?
Если это предложение поучаствовать в разработке - где твой проект на гитхаб? У меня уже почти готовый CoC.md для нее есть. Ну там про "почитай день субботний" и все такое.
В Новогоднюю субботу Рош ха-Шана нельзя не то что в память что-то писать, но даже кнопки нажимать.
Только правой рукой. Носом или хером - пожалуйста.
>> В Новогоднюю субботу Рош ха-Шана нельзя не то что в память что-то писать, но даже кнопки нажимать.
> Только правой рукой. Носом или хером - пожалуйста.Вы оба недопонимаете смысл Шаббата. И правой рукой можно и носом и хером и гою задиктовывать. Главное чтобы ничего путного не получилось что можно было бы назвать словом "работа".
Сходить с ума в Шаббат священное писание не запрещает.
ШабатФС :)
А они в курсе, что NVFS уже изобрели примерно в 2002-м?
Лёня там постоянно что-то переизобретает и переписывает.
Когда уже сделают интерфейсы к samsung ssd для работы inline шифрование (linux kernel 5.8+) на самой ssd?
Правильно ли я понимаю что UFS и FFS должны показывать отличные результаты на флеш накопителях?
> Правильно ли я понимаю что UFS и FFS должны показывать отличные результаты на флеш накопителях?А они не показывают?
А как обстоит дело с выделением CO2 ?
Вот сейчас выйдет Рейзер он запилит РейзерФС и держитесь...