| 1.2, НяшМяш (ok), 22:21, 16/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Мне понравилось, что для простой и надёжной tm файловой системы есть Принципы Работы (Principles of Operation "PoO") в 100 страниц.
| | |
| |
| 2.3, q (ok), 22:30, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
В сложных и ненадежных файловых системах эти 100 страниц придется восстанавливать в уме, браузя тысячи и тысячи строк лапшевидного кода. Документ с дизайном перед реализацией -- хороший подход. Ошибки, обнаруженные в документе перед реализацией, фиксятся легче всего, потому что код еще не написан.
| | |
| |
| 3.4, Аноним (4), 22:34, 16/03/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>В сложных и ненадежных файловых системах эти 100 страниц придется восстанавливать в уме
можно просто делать бэкапы.
| | |
|
|
| 1.6, Аноним (6), 22:43, 16/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Зачем нужна эта ФС, если есть Btrfs в ядре? По тестам Фороникса, она медленнее и нестабильнее, чем Btrfs.
| | |
| |
| |
| |
| 4.9, Аноним (7), 23:14, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
Вы хотите сказать, что нормальный человек будет собирать этажерку LVM + BTRFS, когда BTRFS имеет практически все что и LVM, кроме кривого рейда?
| | |
|
| 3.13, Аноним (6), 23:34, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
В Btrfs RAID5/6 тоже работает для данных. Для метаданных сойдет RAID1.
| | |
| 3.14, Аноним (6), 23:36, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>А в btrfs нет и никогда не будет
Не бреши, в Btrfs внедрили Raid Stripe Tree, что решает проблему Raid5/6.
| | |
| 3.20, penetrator (?), 00:24, 17/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
mdadm?
получаешь блочное устройство, дальше делай что хочешь, хочешь btrfs, хочешь sfrtb
LVM не нужен, он корявый
| | |
|
|
| 1.10, Аноним (10), 23:15, 16/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> В будущем планируется переписать на Rust и компоненты ФС, работающие на уровне ядра.
Ну, если такое обещает, то и смотреть в сторону этой ФС не стоит.
| | |
| |
| 2.11, Аноним (7), 23:17, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
Правильно, куда-же без какого-то RCE в файлухе при чтении картнки из кеша браузера.
| | |
| |
| 3.12, Аноним (12), 23:27, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
А хоть в одной файлухе написанной на Си была RCE при чтении(!) картинки из кеша браузера? Или у тебя прям фс занимается парсингом картинок?
| | |
| |
| 4.15, Аноним (7), 23:44, 16/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
В архиваторах точно было, хотя они файлы как-то не парсят. Не удивлюсь, если и с фс было, ну или будет, если продолжать писать на языке, который компилирует все, что ни попадя.
| | |
|
|
| 2.22, Аноним (22), 01:06, 17/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
Конечно не стоит.
Надо смотреть на надежные системы на СИ, типа ext4:
CVE-2022-1184 use-after-free - local attacker with a user privilege to cause a denial of service.
CVE-2023-2513 use-after-free - allow a privileged local user to cause a system crash
CVE-2024-0775 use-after-free - user to cause an information leak problem while freeing the old quota file names
CVE-2024-43828 integer overflow - may happen causing an
infinite loop in this function, easily reproducible using fstest generic/039.
CVE-2018-10880 - stack-out-of-bounds write - cause a system crash and a denial of service.
А еще можно процитировать анона из старой темы [1]:
CVE-2022-1184 - ваще шикарная.
А теперь микрофон и все лавры передаются ox55ff с лора
"в 2013 году он закоммитил вот такую портянку github.com/torvalds/linux/commit/dc6982ff4db1f47da73b1967ef5302d6721e5b95
Через 9 лет (2022 год) тысячи глаз наконец-то рассмотрели там уязвимость CVE-2022-1184.
Которую смогли исправить только со второй попытки:
первая github.com/torvalds/linux/commit/65f8ea4cd57dbd46ea13b41dc8bac03176b04233
вторая github.com/torvalds/linux/commit/61a1d87a324ad5e3ed27c6699dfc93218fcf3201
ext4: check if directory block is within i_size
Бгг. Видимо Теодорчик решил, что в его коде всё within, ведь "индекс проверять надо если программист решил что тут есть шанс того, что он окажется некорректным", а оказалось, что не within. Это какое-то шанс-ориентированное программирование. Сишник к успеху шёл, не получилось, не фартануло.
-----------------------------
[1] opennet.ru/openforum/vsluhforumID3/136231.html#130
| | |
|
| 1.18, Аноним (18), 23:54, 16/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Стабилизирована операция раскрутки (rewind) журнала.
Это что такое? Откат изменений при потере питания? Или что-то другое?
| | |
|