The OpenNET Project / Index page

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



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

"Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от opennews (??), 21-Апр-26, 20:43 
После шести с половиной лет разработки опубликован релиз пакета NTFS-3G 2026.2.25, включающего свободный драйвер, работающий в пространстве пользователя с использованием механизма FUSE, и комплект утилит ntfsprogs  для манипуляций с разделами NTFS. Код проекта распространяется под лицензией GPLv2...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65262

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

Оглавление

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


1. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (1), 21-Апр-26, 20:43 
Для чтения с ntfs - сойдет. А вот если писать большие файлы на ntfs, возникает жуткая фрагментация.
Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от Аноним (5), 21-Апр-26, 21:27 
Double Commander не проверяли? У него есть опция "Резервировать место", включено по умолчанию https://doublecmd.github.io/doc/ru/copymove.html
Ответить | Правка | Наверх | Cообщить модератору

20. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (20), 22-Апр-26, 00:23 
В Midnight Commander тоже есть. Правда, резервирование места на NTFS очень тормозное, т.к. тупо заливает добавленное место нулями. Т.е. при копировании файл записывается дважды.
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск NTFS-3G 2026.2.25"  +1 +/
Сообщение от dannyD (?), 22-Апр-26, 06:39 
надо будет проверить и обязательно выключить....

---

проверил - ок

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

56. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от cheburnator9000 (ok), 22-Апр-26, 16:39 
Под вендой оно нормальное. Это в линуксовых драйверах не хватает какой-то функциональности. А вот exFAT под вендой точно также медленное, будто нулями записывает (на SSD).
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

2. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (2), 21-Апр-26, 20:43 
Ждем ntfsplus чтобы избавиться от этого legacy
Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск NTFS-3G 2026.2.25"  +3 +/
Сообщение от Аноним (4), 21-Апр-26, 21:17 
Это "ждём" движется по кругу в некоторых средах.
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск NTFS-3G 2026.2.25"  +7 +/
Сообщение от Аноним (9), 21-Апр-26, 22:15 
Голосом Каневского: "От легаси, конечно, избавиться, не удалось..."
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

11. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Другоанон (?), 21-Апр-26, 22:55 
Так ntfp(plus) чел 4 года, если не ошибаюсь, переписывал, с учетом последних фитч ядра. Так что там по идее от старого драйвера остались рожки да ножки.
Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск NTFS-3G 2026.2.25"  –4 +/
Сообщение от Аноним (13), 21-Апр-26, 23:23 
Кто такой Каневский? Это какое-то legacy?
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

39. "Выпуск NTFS-3G 2026.2.25"  +3 +/
Сообщение от Аноним (39), 22-Апр-26, 09:54 
один из мантайнеров ядра
Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором  +/
Сообщение от Аноним (77), 23-Апр-26, 06:01 
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

22. "Выпуск NTFS-3G 2026.2.25"  +5 +/
Сообщение от Аноним (22), 22-Апр-26, 00:48 
Что-то подсказывает, именно это "легаси" и будет работоспособно. Впрочем, как и раньше.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

41. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от пох. (?), 22-Апр-26, 10:28 
Но заметь - ОПЯТЬ новую версию приурочили к выпуску (опять нового) kernel space драйвера.
Так что польза от корейца все же есть.

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

71. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (71), 22-Апр-26, 21:46 
Я подозреваю не к выходу верси ядра приурочили, а к мифической модели от Anthropic, которую в гглаза никто не видел потому что ОЧЕНЬ ОПАСНО. Может оказаться, что модель там - это просто скупленные даркнете уязвимости + десяток элитных вайтхетов, а нам рассказывают про ПРОРЫВ!!!111
Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от Аноним (4), 21-Апр-26, 21:15 
Пару раз он замечательно порол мне файловую систему.
Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от cheburnator9000 (ok), 22-Апр-26, 16:43 
Ntfs-3G лучше использовать только read-only, тогда он не записывает никаких метаданных в раздел.

Вот кстати после ядерного ntfs модуля от paragon после перезагрузки в windows, венда вечно ругалась что ФС на разделе "повреждена", а штатное "проверка и исправление" ничего по факту не исправляло (видимо обновленные метаданные из под линукса не нравятся винде).

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

6. "Выпуск NTFS-3G 2026.2.25"  +1 +/
Сообщение от Аноним (6), 21-Апр-26, 21:28 
а Парагоновский, который тоже обновился?
https://lore.kernel.org/lkml/20260420150756.6058-1-almaz.ale.../
Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (5), 21-Апр-26, 21:46 
В 7.1-rc1: исправления кто-нибудь бэкпортирует в 7.0?
Я просто не очень в курсе, как это происходит. Или подобным занимаются мейнтейнеры дистрибутивов?
Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (26), 22-Апр-26, 01:34 
Вы б ещё дроп 486 предложили бэкпортировать. И принудительно скот обновить.
Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (-), 22-Апр-26, 03:34 
> Вы б ещё дроп 486 предложили бэкпортировать. И принудительно скот обновить.

А у кого-то еще действующий 486 остался с современным линухом на нем?

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

37. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (37), 22-Апр-26, 08:45 
>> Вы б ещё дроп 486 предложили бэкпортировать. И принудительно скот обновить.
> А у кого-то еще действующий 486 остался с современным линухом на нем?

Нет, конечно, но бэкпортировать все равно надо :)

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

47. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (-), 22-Апр-26, 12:20 
> Нет, конечно, но бэкпортировать все равно надо :)

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

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

58. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от cheburnator9000 (ok), 22-Апр-26, 17:05 
Йопт обновись уже хотя бы до https://www.ozon.ru/search/?from_global=true&text=i5-4590S цена 2500 рупий. Будет тебе x86-64-v3.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

60. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от пох. (?), 22-Апр-26, 17:28 
это у него будет - значок. Недорого, но неудобный, потому что с некоторых пор нужно покупать отдельную заколку чтоб держался на пиджаке. (то ли дело 486!)

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

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

8. "Выпуск NTFS-3G 2026.2.25"  +4 +/
Сообщение от Аноним (37), 21-Апр-26, 21:52 
работает оно нормально. нужно не часто. проблем за 10+ лет с ним не ловил
Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск NTFS-3G 2026.2.25"  +3 +/
Сообщение от Аноним (10), 21-Апр-26, 22:20 
Чет все зашевелились после принятия в ядро ntfs plus, который теперь просто ntfs. Наверное это все хорошо, хотя лучше бы раньше они активничали
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск NTFS-3G 2026.2.25"  +1 +/
Сообщение от mshewzovemail (ok), 21-Апр-26, 23:03 
А оно поддерживает сжатие NTFS?
Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск NTFS-3G 2026.2.25"  +4 +/
Сообщение от Аноним (14), 21-Апр-26, 23:24 
Поддерживает. Ещё поддерживает сжатие из одиннадцатки на reparse pointах, но нужен плагин. И даже дедупликацию, тоже на reparse pointaх, но там плагин вообще написан на си шарпе и через клей приклеен к коду на си.
Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск NTFS-3G 2026.2.25"  –2 +/
Сообщение от Аноним (15), 21-Апр-26, 23:27 
Повторю вопрос: когда ваш хвалёный BTRFS в линуксовом варианте впилт поддержку reparse pointов на eBPF, и вообще reparse pointы как first-class citizens? Никогда. Когда он трекать свободное место будет не деревьями, а битмапами, как все нормальные ФС делают? Тоже, наверное, никогда.
Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск NTFS-3G 2026.2.25"  +4 +/
Сообщение от Аноним (16), 21-Апр-26, 23:51 
Лол, динамические структуры это и есть нормальный подход, а не плейн битмапы, как деды в сорок первом
Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (24), 22-Апр-26, 01:22 
Если вы готовы платить за оверхед, и терпеть развалы. Свободное место НИКОГДА нельзя трекать указателями, будут как в FAT пересекающиеся файлы, когда в результате глюка или bit rot перехлестнулся указатель, и свободное место теперь на настоящий файл указывает, а дальше аллокатор берёт и выделяет место друому файлу прям в том же файле, и вашим ценным данным настаёт капут. Причём что новым, что старым, chkdsk отличить легитимного владельца не сможет оодного от другого, и либо скопирует и разбирайтесь сами, либо потрёт. Поэтому для таких структур без контрольных сум совсем нельзя, но в FAT обходились. А хранить контрольные суммы на каждый экстент свободного места - накладненько будет. В битмапе можно весь битмап просто кодами коррекци накрыть, не говоря уже о том, что битмап находится в конкретном заранее известном месте на диске, обычно с максимальной линейной скоростью, и одним куском, и не надо по всему диску головки дёргать. Если вы хотите сэкономить на чтени, то вы можете под битмап на дииске полностью место выделить, но хранить его в виде жатого битмапа, соответственно читать не блоки битмапа разжатого размера, а блоки жатого. Ничего лучше битмапа для трекинга свободного места так и не придумали.
Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск NTFS-3G 2026.2.25"  +1 +/
Сообщение от Аноним (24), 22-Апр-26, 01:28 
А в BTRFS битмап не используют потому, что битмап не очень хорошо совместим с copy on write, либо накладненько будет, либо придётся хитрить и зворачиваться, а там в спеке на BTRFS заявляется, что базовый слой ФС-базы данных укладывается в три сишных структуры, поверх которых всё и строится. А сам битмап - это и есть база, добавлять ещё и его в базовые структуры рушит эстетиику проекта. Хотя у нормальных людей эстетика - это не в красивиости внутреннего мира, а в обеспечении впролне потребительских свойств: надёжностии, скорости, фич. А с первым и вторым у BTRFS всё плохо.
Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (-), 22-Апр-26, 03:27 
>  А в BTRFS битмап не используют потому, что битмап не очень хорошо совместим

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

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

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

40. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (40), 22-Апр-26, 10:12 
ОТкуда такая уверенность, что при использовании каких-то других методов фс не пойдёт по ** * "в результате глюка или bit rot"?
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

70. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (70), 22-Апр-26, 21:42 
Конечно диск может накрыться всегда. Но контроль целостности именно данных - это не должно быть прибито гвоздями менно к ФС.
Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от Аноним (20), 22-Апр-26, 00:28 
Reparse point'ы - это гибко, но это вынужденное зло в винде с её убогой системой монтирования. В POSIX-системах любой mount point, по сути, и есть reparse point. Хранить их как объекты ФС - это костыль и черевато граблями.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

23. "Выпуск NTFS-3G 2026.2.25"  –3 +/
Сообщение от Аноним (23), 22-Апр-26, 01:12 
Reparse Pointы это вообще не про монтирование. Да, поверх них реализовали и точки монтирования, и симлинки. Но суть не в этом, а в том, что reparse point - это просто специальная метка для драйвера "это файл НЕВОЗМОЖНО правильно обработать без такого-то плагина, и ты, дорогой драйвер, этот плагин задействуешь, это не опционально, как ADS". При этом в самой reparse point можно максимум хранить 4 кибибайта, остальное - в самом файле или в ADS. И это я вам скажу - подход здорового человека, а не курильщика. Поверх них можно много чего реализовать. Ещё больше можно реализовать, если сделать фильтр-драйвер, берущий из реестра список опциональных reparse point, которые таки можно обработать без плагина в особо крайнем случае, но совершенно не нужно так делать, и проверяющий наличие в системе фильтр-драйвера для конкретного идентификатора, и если его нет - просто выдающий файл как есть. Так, например, можно прикрутить коды Рида-Соломона с фоллбеком если фильтр-драйвера нет. То есть в ADS хранить чексумму и par2 для блоков, и проверять при чтении, но если нет драйвера с этой фичей - в систему поставить драйвер-заглушку, который просто будет выдавать файлы как они есть, не проверяя и не обновляя хеш-суммы и коды. И никакой BTRFS не нужен c data=dup, коды рида-соломона вообще по месту меньше оверхед будут иметь, чем дубликация. А вот рефлинки так сделать не получится, тут фильтр-драйвер обязателен. Рефлинки можно сделать так: сам файл пишется как последовательность номеров инод, при чтении блока ходится по адресу, при записи блока - выделяется файл размером с блок, и его номер иноды заносится в файл. Заметь, это не ависит от ФС, при наличии в ядре и в ФС механизма reparse points, это можно хоть поверх ext4 сделать, главное чтобы было как хранить сами reparse points, к ext2 их можно на xattr на скотч приделать, но вот в более молодых системах желательно как first class citizens. В случае ядра линукс вместо драйвера с доступом ко всему ядру сам фильтр-драйвер может быть сделат в виде программы eBPF.
Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (28), 22-Апр-26, 02:27 
Какая дичь, что тебе мешает хранить файлы как файлы и открывать их соответствующими программами? может тебе mp3 проигрывателя в драйвере фс не хватает

Какие плагины? чтобы что? чтобы экономить 3кб озу или что, или чтобы тебе всякие васяны ушатывали фс своими поделками

> Ещё больше можно реализовать

Можно что угодно реализовать, бери fuse и вперед, в линуксе даже такое есть, с примерами на любом языке в отличии от этих ваших божественных оболочек доса

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

68. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (68), 22-Апр-26, 21:11 
FUSE не замена reparse pointам. Она требует явного монтирования, а reparse pointы работают прозрачно, как будто это фичи самой ФС. Многие фичи самих ФС, ради которых ФС меняют, можно было бы сделать через reparse pointы, и никаких замен ФС, просто поставил пакет и пользуйся.
Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (69), 22-Апр-26, 21:11 
И да, reparse pointы работают в винде в ядре.
Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (28), 23-Апр-26, 04:14 
То что в винде 30 лет ничего не меняется это не фича, а баг, то что они через костыли добавляют фичи, - слабо подумать зачем? чтобы у людей все работало? нет, чтобы продавать одно и тоже одним и тем же, но с разными шилдиками, вот это вот сервер, и он умеет, а вот это вот нет и поэтому тебе рейд не положен, поэтому даже самая дохлая малинка умеет больше чем самый навороченный комп на базовой винде, как там она называется, домашняя..в общем, ради бога, можешь фапать на что угодно, но иди с этим на сайт виндовозов, ораклоидов или яблофонщиков, тут эти "технологии" проприерастов не любят и не ценят.

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

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

38. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (38), 22-Апр-26, 08:59 
Эт булшит. Парити уже задействуется дисками, твой пример высосан. Да и при передаче по сети битый файл сегодня получить надо постараться. Ну и ты, видимо, не понимаешь, что парити не замена копии.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

54. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (54), 22-Апр-26, 14:47 
Если парити и так есть и спользуется, нафига тогда в BTRFS чексуммы? Может есть далеко не везде, не всегда и не для всех?
Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от пох. (?), 22-Апр-26, 17:31 
хахаха. Посмотрите, до этого начало понемногу доходить.

(нет, конечно)

> Может есть далеко не везде, не всегда и не для всех?

да, в большинстве случаев вообще-то нет ее, там коды рида-соломона. Потому что prml диски (других уже тридцать лет как нет) _принципиально_ не могут прочитать с поверхности то что на нее было записано. By design.
С современными ssd тоже все забавно.

Но ты об этом даже не узнаешь.


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

65. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (65), 22-Апр-26, 21:04 
Про диски я тоже раньше думал, что там, как и вообще в любом носителе с движущимися частями, коды рида-соломона, потом узнал про bit rot и подумал, что таки нет. А вот сейчас мне стало реально страшно. То есть диск у нас тихо сыпется, но коды рида-соломона всё корректируют. А потом вдруг оказывается, что не могут кореектировать, и ВНЕЗАПНО потеря данных, вплоть до потери данных системной зоны, со смертью всего диска..

Тогда нафига в BTRFS вообще чексуммы данных? Если у нас диски такие ненадёжные, то не лучше ли на несколько бит побольше выделить на избыточность, чтобы механика сдохла раньше, чем единственный бит флипнулся?

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

76. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (28), 23-Апр-26, 04:33 
А насколько побольше? а давай на диске будет 50% места под восстановление, чтобы вот вообще супер надежность, только если он физически упадет это не поможет, так и какой смысл? есть бытовые диски, которые пару лет проживут кое как, есть серверные, которые на домашнем компе ты задолбаешься ушатывать, а если тебе действительно надо надежность, то вэлком ту резервирование, через рейд программный или аппаратный, в современном линуксе настроить можно что угодно и как угодно, с двойным, тройным или каким угодно копированием, с подтверждением записи или нет, с кэшированием куда угодно, шифрованием, копировании при записи (qcow), транзакциями и прочими плюшками, и нтфс на фоне этого деревянный самокат, который лучше только чем лапти (fat), которые лучше чем ничего, но нормальный человек, если вдруг случится пойдет и в магазине купит обувь, чем будет сидеть себе лапти строгать или самокат.
Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от cheburnator9000 (ok), 22-Апр-26, 17:19 
>> по сети битый файл сегодня получить надо постараться

Роскомнадзор тебе в помощь, спроси их они помогут.

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

62. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от пох. (?), 22-Апр-26, 17:32 
не помогут, он просто своего файла вообще никогда не увидит. Битый получить - надо что-то ну очень уникальное сотворить.

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

66. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (66), 22-Апр-26, 21:07 
Обрезанный, одну головку доставят, 1 кибибайт. Белый список давно уже на проводе. Блог того же ревуа хрен откроешь, сайт BRFS, и вообще подавляющее большинство сайтов.
Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (67), 22-Апр-26, 21:08 
Вернее, не сайт BRFS, а сайт bcachefs.
Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (38), 22-Апр-26, 17:55 
Потеря пакетов не приводит к повреждению. Всё, что работает поверх TCP, априори устойчиво. С UDP возможны варианты (отдельное спасибо опциональным чексуммам), но, в целом, тот же QUIC устойчив к потерям.
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

79. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от Аноним (20), 23-Апр-26, 13:43 
> Так, например, можно прикрутить коды Рида-Соломона с фоллбеком если фильтр-драйвера нет. То есть в ADS хранить чексумму и par2 для блоков, и проверять при чтении, но если нет драйвера с этой фичей - в систему поставить драйвер-заглушку, который просто будет выдавать файлы как они есть, не проверяя и не обновляя хеш-суммы и коды.

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

И в этом и есть основная проблема reparse point'ов - они требуют поддержки либо в драйвере ФС, либо в плагине, которого может не быть на конечной системе. При этом типы reparse point'ов документированы примерно никак (до сюда - всё принадлежит Microsoft, отсюда - wild wild west), даже для тех типов, которые реализует Microsoft. И при монтировании ФС ты не узнаешь, поддерживает ли система те reparse point'ы, которые хранятся в этой ФС, без полного сканирования.

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

82. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от нах. (?), 23-Апр-26, 14:17 
> Ага, а потом раздел монтируется на системе с поддержкой Рида-Соломона и половина
> файлов не читается из-за несовпадающих чексумм. Да и вообще, чексуммы, которые,

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

Почему эта мысль первой не посетила твою голову и почему вместо этого ты выдал на гора бред?

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

вот расскажи это моей md5sum

> И в этом и есть основная проблема reparse point'ов - они требуют
> поддержки либо в драйвере ФС, либо в плагине, которого может не

reparse point'ы не совсем то что там аноним придумал. Они говорят тебе "это не файл, это информация о нем, где файл и как его достать знает вон то" - ты его и прочитать-то не сможешь без вон того или его аналога. А тут дополнительный атрибут - "да, это файл - но у него есть скрытая часть, что там лежит - знает вот это". В общем-то в EA все это и так есть, толку правда чуть. Можешь туда и чексамы сложить.

Нужно ли оно нам такое - неведомо, но он хотя бы логичен в своей хотелке.

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

29. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (-), 22-Апр-26, 03:19 
> Когда он трекать свободное место будет не деревьями, а битмапами,

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

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

64. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (64), 22-Апр-26, 20:52 
В смысле тормозит? Битмапы наоборот очень быстры. Ещё быстрее - битмапы с индексом.
Ответить | Правка | Наверх | Cообщить модератору

27. "Выпуск NTFS-3G 2026.2.25"  –3 +/
Сообщение от Аноним (27), 22-Апр-26, 01:45 
Ещё продублирую
ФС в принципе может быть модульной. То есть один класс для трекинга свободного места, другой класс для структуры айнодов,
третий класс для папок, четвёртый для аллокатора, пятый - для реализации суперблока, шестой - для экстента, седьмой - для связывания экстентов друг с другом,
восьмой - для файлового слоя и его трюков вроде reparse points, девятый - для хеширования, и т. д. И всё взаимодействует с обобщённым ядром ФС через
абстрактные интерфейсы. После чего конкретную ФС можно будет собрать просто выбрав реализации примитивов.
1. выбрав нужные реализации можно обратно собрать одну из существующих ФС, которые разобрали на примитивы.
2. заменив примитивы на примитивы-разветвители, и включив в них оригинальные примитивы можно держать несколько параллельных систем с одними и теми же данными.

3. поменяв примитивы-разветвители с параллельных на проверяющие-создающие и обойдя все файлы - получаем in-place недеструктивную конвертилку ФС.
4. вставив примитивы-переходники в нужные места получаем трюки блочного слоя (LVM2, Storage Spaces, RAID)

В общем очень гибкая система могла бы быть.

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

42. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (40), 22-Апр-26, 10:36 
Чувак, ты гений! Теперь при развале ФС, порче данных, и вообще, при любом глюке, авторы модулей смогут перепихивать ответственность друг на друга, постоянно устраивать свары по поводу толкования АПИ интерфейса между примитивами, форкать модули, форкать весь продукт ради выбора другого набора модулей, и так далее.
Ты не задумывался - почему так не делают? Почему ФС выкатывается как цельный продукт? Потому что разброд и шатание - это не то, что можно себе позволить при разработке такого фундаментально важного продукта, как ФС.
Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от пох. (?), 22-Апр-26, 10:49 
чо ж у вас афтыри все как на подбор такое г-но?

Ну ничего, rhbm уже наняло им нормальных индусов с палками. (и смотри-ка - как бы ни был ужасен бутерброд lvm-thin-xfs - он работает. Видимо перекладывателей ответственности там как тех крокодильчиков...)

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

46. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (-), 22-Апр-26, 12:18 
> чо ж у вас афтыри все как на подбор такое г-но?

То что в реальном мире - единорогов и розовых пони не бывает. Как и программистов которые совсем не ошибаются. А с учетом масштаба задачи он таки - покушает гамна лаптем на все 200%. Шишкин с своим шишкинфс4 уже проверял - неподъемно получится и за время кодинга успеют условия задачи поменяться.

> Ну ничего, rhbm уже наняло им нормальных индусов с палками. (и смотри-ка
> - как бы ни был ужасен бутерброд lvm-thin-xfs - он работает.

Но саппорт от rhbm лучше все же купить. Потому что если вдруг что где не так - ну и что ты будешь делать тогда?

> Видимо перекладывателей ответственности там как тех крокодильчиков...)

Удачи тебе в менеджменте всякими сратисами + xfs. Я конечно понимаю что пох. не был бы пох. если б не советовал самый залетный и хреновый вариант из всех доступных назло бабушке, но все же.

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

50. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от пох. (?), 22-Апр-26, 12:57 
> То что в реальном мире - единорогов и розовых пони не бывает. Как и программистов
> которые совсем не ошибаются.

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

> Но саппорт от rhbm лучше все же купить.

"а придетца". Хотя бы для доступа к документации (на шв260дкин код!) за пэйволом. (ну и к нормальным версиям а не вечной пре-альфа)

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

> Удачи тебе в менеджменте всякими сратисами + xfs.

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

Удивительно, правда?

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

72. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (40), 22-Апр-26, 22:24 
> хамить вот не стоит

забавное заявление от главного хама опеннета

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

52. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (52), 22-Апр-26, 14:25 
Авторы чего угодно могут при желании вообще всех послать в след за кораблём, и хрен ты такое вообще оспоришь. А модульность как раз позволяет тестировать компоненты ФС отдельно друг от друга. И менять компоненты одни на другие просто ради того, чтобы исключить проблемного автора компонента из цепочки поставок. Можно не один на другой, а просто на форк, другой пакет.
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

73. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (40), 22-Апр-26, 22:25 
А зачем оспаривать? Пожал плечами и послал авторов самих той же траекторией.
Ответить | Правка | Наверх | Cообщить модератору

74. Скрыто модератором  +1 +/
Сообщение от Аноним (74), 23-Апр-26, 03:00 
Ответить | Правка | Наверх | Cообщить модератору

81. Скрыто модератором  +/
Сообщение от нах. (?), 23-Апр-26, 14:02 
Ответить | Правка | Наверх | Cообщить модератору

45. "Выпуск NTFS-3G 2026.2.25"  –1 +/
Сообщение от Аноним (-), 22-Апр-26, 12:13 
> В общем очень гибкая система могла бы быть.

Было уже такое. Reiser4 называлось. А потом и Reiser5. В силу сложности и масштаба задачи vs постоянной смены правил игры типа пришествия ssd и сверхскоростного io - оказалось нахреннужно и труднореализуемо. Так что вся эта вавилонская башня оказалась vaporware в основном.

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

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

53. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (53), 22-Апр-26, 14:45 
Задача действительно огромная и нафиг не нужная лично разработчикам ФC: модульность усложняет дизайн, а автор ФС обысно разрабатывает вполне конкретную ФС с конкретными решениями относительно модулей, если он выбрал такие модули - значит он ТИПА верит, что эти модули - наилучший компромисс, знакчит другие модули - просто не нужны, значит интерфейсы - излишни. Но это не та парадигма. Та парадигма - это смотреть на систему на более высоком уровне, как на фрейворк, а конкретные модули - это вообще не забота архитекта, забота архитекта - это межмодульные интерфейсы и middleware между ними, причём даже не на уровне кода, код вам и Клод напишет, а на уровне спецификаций. Райзера на свободе в бытность свою на линуксе не застал. Возможно, если бы Ханса не закрыли, то это всё-таки было бы реализовано. Но теперь даже Шишкин проект забросил. Возможно, наличие вайб-инструментов позволит кому-то за это взяться и довести, но я - не буду. И есть сильные сомнения, что Reiser4 такой был, если бы такой фреймворк уже был - то рационально было бы делать любые ФС на основе этого фреймворка, в этом ведь вся суть, что можно взять и собрать свою ФС из готовых модулей с минимумом самописных модулей, декларативной конфигурацией, задающей потоки данных.
Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск NTFS-3G 2026.2.25"  +1 +/
Сообщение от Аноним (55), 22-Апр-26, 14:57 
Не настолько у них модульность была, как вышеотписавшийся предлагает. Reiser4, всё же, минимально монолитная. Её, как простую ФС, можно использовать без внешних модулей.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

78. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от Аноним (78), 23-Апр-26, 07:48 
Странная вещь приключилась. На винде в виртуалке распаковал установщик им самим, перекинул на NTFS-диск на линукс-хосте под ntfs-3g через 7z-архив и общую папку виртуалбокса, архив распаковал 7z. Вот теперь я подключил диск к винде ... и огрёб проблем именно в распакованной папке, там откуда-то взялась страння запись в MFT, такой папки вообще попросту нет на диске, но аттрибут для неё откуда-то взялся. Также на томе откуда-то взялись NTFS-сжатые файлы, причём тоже распакованные из инсталлятора (другого), и таким же образом на хост перекинутые. Я офигиваю, вроде бы NTFS-сжатие вообще не должно так передаваться, тем более в ntfs-3g. Что это вообще было?
Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск NTFS-3G 2026.2.25"  +/
Сообщение от нах. (?), 23-Апр-26, 13:58 
> Что это вообще было?

umount забыл набрать, или дефективная флэшка/кабель/контроллер, обычные битые структуры фс

нет, в ntfs3g таких багов нет.

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

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

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




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

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