Константин Комаров, основатель и руководитель компании Paragon Software, опубликовал в списке рассылки ядра Linux набор патчей с полноценной реализацией файловой системы NTFS, поддерживающей работу в режиме чтения и записи.Код открыт под лицензией GPL...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53554
"проведения рецензировния предложенного кода"
т.е. до этого код тупо впихивали, не проверяя?
Для включения кода в ядро кто-то посторонний с заслуженным авторитетом должен проверить код и подписаться под патчами.
Ему за это заплатят?
> Ему за это заплатят?Судя по минусам, нет
у Анонима с опеннета достаточно авторитета для сего действия? :D
Нет, слишком много. Анонимы такой мелкой ерундой не занимаются.
Как корневую фс теперь ntfs юзать можно будет?
Даже если и станет можно - идея не то, чтобы "айс"...
ФС как ФС. Так что идея вполне жизнеспособна. Особенно для дуалбутчиков и прочих БСДшников.
Да нет, производительность заметно ниже, а к тому же ФС знатно фрагментируется. Не нужно.
Заметно ниже чем что? У нас тут этих ФС на любой вкус: хочешь тормознутые, хочешь теряющие данные, есть поддерживающие файлы до 100 Хринибайт, но не больше 78 штук, а есть кластерные ФС, монолитные ФС, стековые ФС... Ну вот только про ФС со вкусом политэкономии я не слышал. А всё это безобразие срёт логами, и всячески берется за выживание как тараканы в банке с солидолом. NTFS на этом фоне ну вообще ничем не выделяется.
>фрагментируетсяКто-то фрагментируется, у кого-то иноды заканчиваются, кто-то не выравнивает начало файла по началу сектора-кластера... Просто ещё одна особенность. В крон пропишешь запуск дефрагментатора раз в месяц.
> дефрагментатораНет уж, померла так померла.
Меня забавляет что в линухе отсутствие чего-либо подаётся как преимущество, а не как недостаток. Дефрагментация — неплохая вещь, вне зависимости от прочих факторов.
Большинство ФС, которые разрабатывались по классической NIX-архитектуре, не требуют дефрагментации. Это потом пошло, всякие основанные на принципе COW.
Почти совсем не требуют. Но если вдруг, то:
ext4: e4defrag
xfs: xfs_fsr
Именно!
Можно сделать как надо немногим инженерам. Вместо хипстера с Маком.
И вне зависимости от типа диска HDD/SSD?
> И вне зависимости от типа диска HDD/SSD?Да. На SSD фрагментация вместо тормозов обычно вызывает заметные скачки загрузки CPU.
не очень удачная идея дефрагментить RAID-0 терабайт этак на 16 а то и 32
Почему?
> Почему?потому что это HDD массив, скорость случайного чтения небольшая... дефрагментация на 32 терабайта может с легкостью отнять 2-3 дня
> дефрагментация на 32 терабайта может с легкостью отнять 2-3 дняЧто-то я сомневаюсь. Особенно если делать это регулярно.
А поддерживающие нормальные имена файлов есть? Нормальные - это с максимальной длиной больше 255 байтов. NTFS и ReFS в винде это могут, exFAT тоже. В кocтылинупce же во что палочкой ни ткни - 255 байт и отвали, что нередко генерит кучу лулзов.
https://wiki.etersoft.ru/Linux/VLFN
Благодарю, но это реально лютый набор костылей.
1. На всяких ext2/3/4 не сработает, поскольку на хранение длины имени файла там всего один байт.
2. Скорее всего винт с btrfs, записанный на такой машине не прочитается на других, шаманству не подвергнутых.
Ось и софт у разумных людей давно уже стоит на SSD, а на файлохранилище (не люблю вот это слово «помойка») проблемы фрагментации особо и нет.
вообще-то естьпредставим какую-нибудь торрент хранилище засранное почти рандомно
а теперь из этого торрент хранилища нужно скопировать данные
линейная скорость будет очень большой (у меня рейд 0 и 10GbE), а вот рандомное чтение будет убогое в десятки раз меньше
Кто-то торрентом еще пользуется ввиду наличия Netflix, Spotify и пр?
1-го канала и рен-тв
Ты совсем дурак что ли?
> Ты совсем дурак что ли?Да не, просто для него использовать торрент значит пиратить, а для многих других это просто способ файлового обмена. ;)
Не значит. Ну юзаю торрент епизодически, но у оратор выше говорит про торрент-хранилище. Там что одни дистрибутивы?
> Не значит. Ну юзаю торрент епизодически, но у оратор выше говорит про
> торрент-хранилище. Там что одни дистрибутивы?там все что скачал.. дистрибутивы, фильмы, все что на текщий момент скачано и раздается другим
да хоть какие-то базы... или массивы данных для обучения нейронок
какая в жoпу разница какой контент.. торренты - это самый простой и эффективный способ обмена данными
мой комп - это полноценная нода, которая не вырубается...
не надо путать с хомячковыми оконечными устройствами тупеньких потребителей
> ФС знатно фрагментируетсяОчередная опеннетная страшилка из серии 'ZFS после пропадания електричества починить можно только HEX-редактором'. Катит только для местной аудитории.
Там было такое что сжатые силами NTFS файлы имели свойство сильно фрагментироваться при модификации (20 лет тому назад). Но сравнивать с линуксом это глупо т.к. тогдашние пингвино-FS в сжатие банально не умели.
> (20 лет тому назад). Но сравнивать с линуксом это глупо т.к. тогдашние пингвино-FS в сжатие банально не умели.сжатие было даже у ext2. когда? гуглим e2compr, идем на sourceforge по ссылке, ознакамливаемся внимательно и...
> Genesis (Linux 1.2 / 1.3, 1995-1997): http://www.etca.fr/Users/Antoine+de+Maricourt/english/e2comp...но ты об этом не знаешь. странно, я вспомнил тут же.. может быть ты просто не в теме совершенно, отсюда и глупые, зато ехидные посылы в сторону линукса?
25 лет тому, где там винда была со своим "сжатием"..? какую вообще версию венды в 95том году юзал твой отец? спроси у него...
и изучите матчасть прежде чем критиковать, юноша.
Сжатие даже в мсдосе было :)
>> GPL-реализацию NTFS для ядра Linux
> Особенно для дуалбутчиков и прочих БСДшников.Пользователи линукса с дуалбутом в венду у "тру" называется БСДшниками? Невероятная гибкость мыления, но многое объясняет.
а так же те ярые линусоиды, которые уже давно переобулись в wsl
Именно для дуалбутчиков держать Линь на ФС, которую понимает потенциально дырявый сосед - чрезвычайно неудачная идея.
Мне кажется, что большинству из тех, кто держит винду второй системой на дыры наcрать. Т.е. конечно хорошо если их мало, но ничего страшного если их 100500. Кому не наcрать -- заморачиваются второй машиной, виртуалкой или ещё чем погаже.
> Мне кажетсяТитр над головой "Это ему кажется".
Довольно многие оценившие удобство Линуксов для работы держат Винду в дуалбуте для игрушек, например.
ну это изврат.. лучше линуху на отдельной машиневот понадобился тебе трансмишен, а он на линухе и что ты будешь делать?
перегружаться и выходить из игры? ))
> вот понадобился тебе трансмишен, а он на линухе и что ты будешь делать?Если уж я перестал работать и сел поиграться - мне не понадобится трансмишен.
Даже при том, что у меня дуалбута нет, винда в виртуалке и то довольно редко запускается.
это потому что кто-то однозадачный ))
> это потому что кто-то однозадачный ))Когда я уже наработался настолько, чтобы тупо сесть и поиграться - идите все в пень, я вообще беззадачный.
>понимает потенциально дырявый соседОткуда у линуксойдов столько чванства? Дыры есть во всех серьёзных программах. Даже в линухе. Живите теперь с этим.
У всех есть недостатки. Ты, например, пихаешь литеру "й" куда попало.
> Откуда у линуксойдов столько чванства? Дыры есть во всех серьёзных программах. Даже в линухе. Живите теперь с этим.Да вы просто открылй мне глаза!
Дыры, но не бекдоры. И дыры эти чинят.
> Дыры есть во всех серьёзных программах. Даже в линухе.Но у дуалбутчиков их по определению больше.
Давно уже можно при большом желании. Корень на FUSE вполне себе осуществимая затея, непонятно только зачем.
Стоп, стоп, стоп, это то, что мне нужно!
Где об этом можно почитать?
ntfs-3g пакет установи в свой дистр, он установит прослойку fuse и ntfs
Тебе нужна initramfs с включенным fuse и ntfs-3g. И init в виде шелл скрипта на несколько строчек - монтирование ФС и переключение корня.
Ему еще отдельный дистрибутив самодельный нужен - потому что unix permissions ntfs3g не поддерживает а имитирует, и без них сломается практически все.И даже не потому что очень уж надо (подумаешь, исполняемый /etc/passwd, и не такое во времена umsdos видали) а потому что рукожопые скрипты на пихоне не позволят.
(наблюдая в очередной раз приключения скриптов поддержки всего лишь /boot раздела, где атрибуты вообще не нужны низачем и ни для чего - жаль что разработчики де6иллиана об этом уже не узнают, потому что старые сдохли, а новые умеют только в CoC)
Не обязательно.
Корень (и/или бут) можно монтировать ридонли.
После загрузки перемонтировать в рв.
Я так понимаю делать надо как-то так:
1) Монтируем корень ядерным драйвером в ro
2) В скриптах initramfs или где-нибудь попозже монтируем ту же корневую фс другим драйвером (NTFS-3g) в режиме ro наверное.
Это кстати возможно? Ну, смонтировать одно блочное устройство сразу двумя драйверами.
3) Переключаемся через pivot_root на новый корень
4) Отмонтируем старый корень
5) Переключим новый корень в r/w
Очень не советую ибо сам сталкивался с порчей данных! Сырой дравер, ибо спеки не открыты же - лучше как минимум тогда уж этот новый подождать! А вообще к чему это? Для обмена данными тогда уж лучше exFAT юзать, благо спеки открыли, дрова новые приняли
> Для обмена данными тогда уж лучше exFAT юзать, благо спеки открыли, дрова новые принялиОно там такое (ядерное), что лучше в ближайшие пару лет не подходить
Но зачем? Единственный смысл нтфс это дуалбут с виндой, а нафига тебе корень с виндой шарить?
Не всегда. У меня вместо флешки нередко используется подключаемый по USB внешний винт на терабайт. Все домашние железки его в NTFS нормально воспринимают: хоть телек, хоть ноут с компом, хоть роутер. А вот если я его во что линупcячьe форматну - начинаются проблемы.
NTFS-тома без проблем и сейчас монтируются. Для потребительских целей: читать, писать/какать. Другое дело, надо понимать, что виндузычий ACL не является POSIX-совместимым. Поэтому будут проблемы с размещением чего-то системного таком NTFS-томе.
Разве NTFS имеет поддержку всех нужных юниксовых файловых атрибутов? Я просто реально этим не интересовался и мне интересно.
Нет, не имеет.
Лолшта - вот этого вот недоразумения из двенадцати бит?Не, не имеет (posix api там уже двадцать лет как немодно - через него и через backup еще - было можно) - она нормальные hierarchical acls умеет (к сожалению, нет, не posix - шва6одные слоупоке со слоу, что опоздали и изобрели велосипед с квадратными колесами назло врагам).
Теоретически, разумеется, ничего не мешает тебе написать (или на коленках умолить кого-то умеющего кодить) примитивный враппер, транслирующий какой-нибудь ограниченный набор этих acl'ей в юниксное ничтожество (у самой MS такие есть, причем работающие в обоих направлениях - правда, в обратную сторону не очень хорошо), но ты ведь не будешь, ты будешь страдать.
> Лолшта - вот этого вот недоразумения из двенадцати бит?На самом деле эти 12 бит — охренительное решение: простое как угол дома, надёжное и при этом покрывает ~99% задач. Очень легко провести аудит имеющихся прав и легко сделать производительную реализацию. Для всяких однопользовательских систем (с изоляцией сервисов) и простых общих каталогов прямо конфетка.
NT ACL — другая крайность, аццкий over-engineering, в котором можно «слона не складывая спрятать», т.е. очень легко сделать труднообнаружимую дырку в правах (как случайно, так и специально) или долго гадать, почему нужное действие не удаётся и как его разрешить, чтобы при этом не разрешить лишнего. А когда этот замок из костылей всё-таки удаётся собрать, сложность его поддержки и обработки зашкаливает, ибо обработка с учётом иерархии совсем не бесплатна. Но возможности по тем временам занятные, конечно, хотя в итоге практически всем стало понятно, что большую часть странных случаев лучше реализовывать на уровне приложений, а не ФС.
А вот POSIX ACL — да провал, ИМХО. И не туда, и не сюда получилось. Особенно с учётом NFSv4 ACL, которые сделаны куда более толково, да вот только из-за уже имеющихся POSIX ACL их не внедрить массово. Вот за это прям очень больно.
Ну сделай на этих 12 битах разделение прав из серии "вот к этому файлу должны иметь доступ только пользователи из групп "операционисты" и "бухгалтера", причём операционисты файлы только создают, а бухи работают с уже имеющимися. Все остальные идут по известному адресу даже при попытке посмотреть что в этом каталоге такое лежит".
Про 100% покрытие никто не говорил. В данном случае речь сугубо о том что хорошо, когда простые проблемы (задачи) решаются простыми (и максимально дубовыми в хорошем смысле) методами, а не так что есть один тяжёлый микроскоп NT ACL, которым и забиваем все гвозди, независимо от их вида.
Она имеет поддержку расширенных атрибутов, точек повторного анализа, потоков и фильтров.Технически нет никаких ограничений объявить все необходимые атрибуты в метаданных и присвоить им какие-то значения. На самом деле проблемы не было изначально, чтобы реализовать posix-функции нужно было просто написать свои фильтры для ссылок сделать точки повторного анализа там, на что они нужны, понаобъявлять атрибутов сделать утилиты... то есть это вообще не просто ни разу... но технически возможно.
Ну вот в WSL1 MS это и сделал, собственно: https://docs.microsoft.com/en-us/windows/wsl/file-permissions
И что там с SELinux/Apparmor случится на них же тоже атрибуты нужно создавать кучу расширенных атрибутов...Есть только одна беда, открытый драйвер NTFS должен это уметь. NTFS-3G вроде умеет, но умеет только некоторое подмножество этого функционала, причем по вполне понятной причине. Это очень гибкий сложный и редко используемый функционал (когда все кастомное вплоть до фильтров), то что принято в продуктах МС называть оверинжинирингом. Ирония в том, что именно этот функционал и позволяет решить задачу с атрибутами прав posix.
ИМХО гораздо большая проблема - отсутствие совместимости между Posix ACL и NT ACL, добавьте к этому условные ACL (DAC) и несовместимость дескрипторов безопасности. Это тот случай когда Windows не виновата в том, что POSIX ACL такой какой он есть и как погано на Linux работают права, хотя рядом есть тот же NFSv4 ACL, применяемый на той же Macos. Была попытка сделать такое же на Linux, но richacls сдох, да и баранам будет сложно, баранам нужны права на ФС из 1970-х.
>при наличии в ядре старого драйвера fs/ntfs, который работает в режиме только для чтенияПочему работает на запись? Или в ядре уже есть драйвер для чтения-записи?
На запись работает драйвер FUSE (ntfs-3g).
Благодарю за разъяснение.
Он там 20 лет. Вот тот ядерный который только на чтение имеет дополнительную опцию разрешения записи в конфиге ядра, но с криками, что так делать не нужно ни за что и никогда, что у тебя может все полететь в гнезду и мы не виноваты
он там очень оригинально эту запись осуществляет - то есть она даже включенная будет кастрированной и ни для чего полезного непригодной.этот недодрайвер давным-давно пора было выбросить из кода ядра, как абсолютно никем не используемый (и, кстати, неподдерживаемый) - но за это вашему божку rhbm не платит, поэтому выбрасываются совсем другие вещи.
> этот недодрайвер давным-давно пора было выбросить из кода ядра, как абсолютно никем не используемый (и, кстати, неподдерживаемый)Вот тут согласен без вопросов
И сам всегда удивлялся на какой мужской половой орган его сохраняют
Впрочем бесполезного дeрьма которое никто не выбрасывает из-за нытиков в ядре еще больше
Limit of liability: приведённое мнение основано на опыте ~10-15-летней давности.Когда я оценивал пригодность Paragon's NTFS Linux kernel driver (интересовало rw),
то оказалость, что в сравнении с тем, что было в ядре (да, с криками и т.д. и т.п.)
он настолько хуже, что брать его не имело смысла. Я, возможно, упустил какие-то
тонкие моменты, но его производительность и стабильность не лезла ни в какие ворота
(ряд вполне регулярных use-cases не удалось завершить в сколь-нибудь разумные сроки).Код (да, я его видел) и сборка --- это был полный trash.
Для пох: не краденый.
Существенных недостатоков того, что было в ядре (при включении rw) я не обнаружил: для
планируемого использования был вполне годен.Моё впечатление о коде от P. было --- взяли реализацию для W. и на от...ь затолкали под Linux.
Не знаю, что там пытаются отдать сейчас, но по некоторым характерным словам --- там ряд проблем (реально _проблем_) заботливо сохранён.
> Для пох: не краденый.был бы он не краденый - обычно за свои деньги первое что делают - подключают техподдержку, ага.
> планируемого использования был вполне годен.
портить fs и крэшиться? ;-)
> Моё впечатление о коде от P. было --- взяли реализацию для W.
лол. Реализация для W существует только одна - и она принадлежит microsoft, а не paragon. Которому совершенно незачем было что-то переписывать.
> Не знаю, что там пытаются отдать сейчас, но по некоторым характерным словам
> --- там ряд проблем (реально _проблем_) заботливо сохранён.конечно же показать пальцем эти проблемы ты не можешь.
(пока что осмысленные претензии сводились в основном к правкам кернельных сборочных скриптов - вероятно, парагоновцы никогда и не проверяли сборку внутри ядра, а не отдельным модулем, что вполне понятно, и эти патчи они собирались мержить)
Он был получен от P. для оценки ... и т.п.
Пальцем показывать --- вообще дурной тон. Тем более в то, что было снесено немедленно после
оценки.Про реализацию, прина... . Да и ладно. Ведёте себя как подпевала у неформального лидера целых четырёх подъездов.
> Он был получен от P. для оценки ... и т.п.э... в смысле скачатьбесплатнобезсмс? Ну так если на самом деле планировалось для оценки, а не "пройдет время trial - найду кряк", то еще более странно не задействовать техподдержку.
Хорошее начинание. Но бюрократы при ядре хотят, чтобы не только предоставили, но и сделали им удобно.
Потому что именно эти «бюрократы» отвечают перед пользователями.
Ага, прям на опеннете перед тобой отвечают и честь отдают!
Но в случае чего с разборками и криками "у нас терабайты порн^W очень важных файлов на NTFS превратились в кашу из-за вашего shitкода" придут именно к ним, а не к Paragon Software и уж точно не к анонимному комментатору opennet.
Да-да, придут, придут.Какие у гнутых истеричек интересные бредни в головах... (нет)
именно поэтому в тексте лицензии капсом выделен отказ от гарантий? что то ни в одной новости про уязвимости в ядре не видел что бы писали кто написал код с ошибками, кто его смотрел, принимал, был ли пересмотр другого кода этого человека.
> именно поэтому в тексте лицензии капсом выделен отказ от гарантий?Юридических последствий не будет, да. В суд не подадут. Но репутация будет подмочена, как и изнасилован мозг мейнтейнеров. Оно им надо? Поэтому и требуют заранее оформлять код, чтобы его было удобно ревьювить, т.к. отвечать за подсистему и её поддерживать им, а не перцам из Paragon Software, при всём к ним уважении.
CVE с ядре находят чуть ли не каждый день. Баг в blk-mq планомерно уничтожал файловые системы. Патчи в ядре убунты каждые полгода создавали проблемы. Репутация скольки разрабов, мейнтейнеров и кучи бюрократов была подмочена? Все что говорят? "Это опенсорс, тут тебе никто ничего не должен, хочешь лучше - сделай лучше" и вообще "Невозможно писать код без единой ошибки".
Из всего этого, я так понимаю, надо сделать вывод что в ядро надо принимать любую кучу кода забив на ревью?
> CVE с ядре находят чуть ли не каждый день.И? Есть продукт в котором не находили?
> Баг в blk-mq планомерно уничтожал файловые системыПроблема аргумента в том, что blk-mq писали сами мейнтейнеры подсистемы. В сабже предлагается довольно большой патч, от левых незнакомых людей, без сопровождения, который надо отревьювить одним куском. Вот им нужен этот головняк?
Просят хотя бы побить на несколько по функционалу, а также не просто кидать патч, а определиться кто будет поддерживать и что-нибудь написать про плюсы минусы. Ссылку прочитать не трудно, наверно.
В конце-концов правила для того и пишуться, чтобы их соблюдать. Не нравится - с пляжа.
> Из всего этого, я так понимаю, надо сделать вывод что в ядро надо принимать любую кучу кода
> забив на ревью?не можешь ревьюить, и не можешь сам написать - принимай, да. (Борцуны за все хорошее и против всего плохого всегда могут нажать N в make config - если знают что это такое. Если не знают - то не им и решать.) Иначе это типичное опенсосие - перевод чужого времени и труда в /dev/null
> И? Есть продукт в котором не находили?
тогда прекращайте звиздеть о нужном и необходимом ревью. Оно бесполезное (у вас нет квалификациии для этого) и совершенно не необходимое - дальше вы это и подтверждаете:
> Проблема аргумента в том, что blk-mq писали сами мейнтейнеры подсистемы.
"это кого надо нога!" - можно не ревьюить, это правильные пацаны писали!
Проблема в том, что если вы хотите уважения и понимания - то надо либо пороть за такие вещи (вот вплоть до перевода под обязательный контроль кем-то более доверенным (хаха, откуда он возьмется), либо признать что "майнтейнеры подсистем" вовсе не по умениям раздувают щечки, а по факту первого влизавшегося в доверие, и их мнение, конечно, очень ценно, но не должно влиять на принятие патчей, которые они не в состоянии написать сами.
(разумеется, они могут все переписать сами, как им нравится - ровно то, что обычно л@п4атые предлагают делать авторам сторонних патчей - за них)> Просят хотя бы побить на несколько по функционалу
угу. Поддержку (сложной, не exfat такой) файловой системы - порезать помельче, и переподать с поклоном - у божков в экран же ж нивлазиет.
Кто е6анулся? Да вы е6анулись, кто ж еще-то!У нее ровно одна функциональность - поддержка ntfs. Сложные вещи - внезапно, не делаются в десять строк хренового псевдокода, на котором последние пятнадцать лет "программирует" Линус.
Ну вот я и спрашиваю - чья репутация была подмочена кривым blk-mq? Придурошным патчем OOM-killer'а в бубунте? Сломанным nss в glibc? Ничья. Так что все эти разговоры про некие репутацию, разборки и крики из-за гипотетических проблем с реализацией от Paragon тут мимо кассы. Им дают рабочую реализацию ntfs - они нос воротят. Зато прием в апстрим кривущей на тот момент (да и сейчас не особо-то стабильной) btrfs прошел со свистом, несмотря на нарушения регламента. Как верно отметил пох., весь линукс - одна большая "эта нога - кого надо нога!"
> Как верно отметил пох., весь линукс - одна большая "эта нога - кого надо нога!"Просто они не в состоянии объективно оценить качество проекта, предлагаемого для включения. Торвальдс же кроме шелла и 386 архитектуры ничего не знает. А тут файловая система! Причём его же "лейтенанты" недалеко от него ушли. Вот и причина всех косяков. Вместо правильных вопросов просьба "станцевать", подсчёт смайликов в сообщениях, и т.д. Возможности тут поистине огромные. Вспоминается фильм "Вместо меня" со Стриженовым ("А съешь говно!"). Но везунчика, прошедшего эти "испытания" ждёт поистине светлое будущее: он получает мощную поддержку и бесконечныве кредитсы. Даже если проект оказался полностью провальным (как в случае с Btrfs).
> Но везунчика, прошедшего эти "испытания" ждёт поистине светлое будущее: он получает мощную
> поддержку и бесконечныве кредитсы. Даже если проект оказался полностью провальным (как в
> случае с Btrfs).нееет, дорогой - это - опять кого надо нога!
Везунчик получает угрозы "мы опять поломали весь апи - твой код не собирается, срочно чини или выкинем его". Вон lustre - была кого не надо нога - выкинуто, вам не нать, обойдетесь fuse.
Это https://bugzilla.kernel.org/show_bug.cgi?id=201685 ?Kernel Version: 4.19.x 4.20-rc
Regression: YesДа все серьёзные пацаны в то время сидели на не новее 4.15
> Да все серьёзные пацаны в то время сидели на не новее 4.15так им и дальше никто не запрещает на ней сидеть, собственно - и никакой ntfs им не угрожает.
> именно поэтому в тексте лицензии капсом выделен отказ от гарантий?В тексте лицензии, халявной - отказ, капсом.
А в тексте договора, по которому получают деньги те, кто платит зарплату тем, кто потом открывает плоды своих трудов под этой лицензией вам на халяву - внезапно, никаких отказов по чисто техническим причинам нет и быть не может. Так вот, внезапно, не халявщики, а именно эти люди и озабочены этим вопросом в достаточной степени, чтобы сначала требовать то, что там выше уже перечислили, а уже потом радоваться - какой славный код принесло в ядро.
Ахаха, «отвечают»
Действительно, кому нужны эти глупости вроде соблюдения общей архитектуры проекта и хорошего кода.
Абсолютно не нужны - пресловутые правильные пацаны регулярно комитят плохой и вообще неработающий код - и ничего.Причем регулярно с обидными комментариями отбрасываются патчи, исправляющие реальные проблемы. Ведь правильным пацанам не за это каплет бабло.
То есть ты им исправил баг, портящий данные - а тебе в ответ "порежь помельче и переподай с поклоном вдвое пониже!".
А мы продолжим рассказывать сказочки про очень хороший код и какую-то там еще "общую архитектуру" трэша и п-ца.
Хотим Линdows!!!
Было уже когда-то. Только Мелкомягкие наехали тогда на название, типа, оно созвучно с Windows.
Переименование в Linspire им что-то не сильно помогло.
В ядре есть режим записи для NTFS, просто это нужно указывать в ручную при монтировании. По умолчанию только чтение.
Это не тот драйвер. И он не в ядре.
Тот. Возможность записи нужно включать вручную при сборке и она помечена как "experimental" уже много лет и включать это категорически не рекомендуется.
Причем прикол: одно и то же ядро. Собираешь в Ubuntu - глюк на глюке. Особенно с размонтированием. Из тех же исходников компилишь в слаке 14.2 64 - ну все просто норм. И диски sata, и флешки. Все корректно. В чем особенность - я так и не понял.
> Причем прикол: одно и то же ядро. Собираешь в Ubuntu - глюк
> на глюке. Особенно с размонтированием. Из тех же исходников компилишь в
> слаке 14.2 64 - ну все просто норм. И диски sata,
> и флешки. Все корректно. В чем особенность - я так и
> не понял.В том что ты врешь?
Это таки драйвер, хоть и не ведре.
Интересно, позволит ли это исправить низкую производительность в WSL2 при операциях в/в в файловую систему Венды?
В огороде бузина, в Киеве дядька.
нет
Чего это они? Раньше же продавали этот драйвер
exFAT у них не приняли и они решили превентивно NTFS апстримнуть, пока никто не успел. Внизу же написано.
И что им за это будет?
Хотя вон ниже написали, копирайты будут их конторы стоять
Вероятно, не все возможности коммерческой версии они в свободную включили. Кто раскушает, понравится, покупай проприетарную, она расширенная.
> И что им за это будет?чуть меньше приключений со "stable api is nonsense" - ну или они так надеются.
Ну и защита от пакостей вида "с сегодняшнего дня этот и вон тот вызовы апи - только для чатлан с gpl2"А их бэкапный софт от этого покупать ни разу не перестанут.
Может товарищам майорам закладку захотелось. Я бы в первую очередь на процесс монтирования и работы с mft обратил внимание, если и есть что-то, то вероятней всего туда сначала запихали. Искать нужно комбинированные баги, то есть сработка не в одном месте, а в контексте двух-трех операций. Также интересно будет посмотреть на работу с журналированием и откатом, если рассматривать мою бредовое оценочное суждение в этом ключе, то и отсылка с потенциально сырой части может быть легендированием на случай обнаружения подозрительного кода - «это было технической ошибкой» (с) Фейсбук
>Данный шаг был болезненно воспринят в компании Paragon Software, которая выступила с критикой открытых реализаций exFAT и NTFS.Критикуя - предлагай. Молодцы.
Непонятно. Есть ли полные открытые спецификации на NTFS? Или они, как обычно, только у избранных партнеров Майкрософта. Насколько я могу доверять модификацию разделов с NTFS таким драйверам?И Эпл тоже мутные. Когда выкатывали новую AppleFS, обещали, что спеки будут открытыми. Но ничего похожего нет.
МС открыла спеки на NTFS.
Да это был вопрос времени кто первый копирайты занесет в linux mainline
> МС открыла спеки на NTFS.Можно, пожалуйста, ссылку? На моей памяти на FAT/exFAT открывала, да, но не на NTFS.
Гуглить пробовал, нашлись только сторонние документы.
> И Эпл тоже мутные. Когда выкатывали новую AppleFS, обещали, что спеки будут открытыми. Но ничего похожего нет.Они просто её до сих пор не допилили даже на макосе, а вы уже спеки хотите. Ну и да, могли просто лужу газифицировать в надежде, что никто и не вспомнит об этом вообще.
вы на opensource.apple.com давно были? хотя я тут плаваю, может не то опубликовали )
так просили - спеки, документацию что, зачем и как, а не двадцать гигабайт мутного кода операционной системы целиком, из которого надо отдельно выковыривать описания структур, и отдельно логику.Ну, уцелом, есть мнение, что его у эпла и нет, хреначили с листа. Собственно, такое же мнение есть и про ntfs - что никакой документации по нему не опубликовано ровно потому, что ее у ms никогда не было, а то что было - не соответствует реализации. Вот на все варианты fat, кроме, может 32 - была, так она и опубликована. Ну так это ibm небось их заставила документировать прежде чем делать. А exfat документировали ради патента.
Ничего удивительного, в общем-то - покажите полноценную документацию на ext4, lvm, ну или даже btrfs.
"система хорошо документирована исходным кодом", тьфу...
Что-то похожее есть:https://developer.apple.com/support/downloads/Apple-File-Sys...
Но, конечно, этого худо-бедно достаточно только для чтения: структуры более-менее описаны, а алгоритмы - практически не.
Да нет никаких "спеков". Их вообще нет. Никто тебе спеки не будет на блюдечке приносить. Код откроют -- вот и ройся.
> Да нет никаких "спеков". Их вообще нет.а вот microsoft на exfat запилила таки - вполне подробные. Но она - корпорация зла, смотри не перепутай!
Ну потому что он простой как пять копеек. И -- не их.
> Патчи оформлены в соответствии с требованиями по подготовке кода для Linux
> В комментариях к публикации также отмечаются проблемы со сборкой и несоблюдение ряда требований по оформлению патчейЩас не понял..
>расширенные атрибуты файлов, режим сжатия данных, эффективную
>работу с пустотами в файлах и воспроизведение изменений из журналаА как же потоки?
Наверное, опции монтирования будут.
Какие же линаксоиды все же лицемеры.На протяжении больше 20 лет желают смерти винде, а сами втихую принимают реализацию NTFS в ядро.
Какое же это лицемерие.
Но вообще это даже забавно читать, как линаксоиды голосят во все горло: "маздай", "майрософт должна умереть!"
И все это на фоне того, Microsoft является платиновым контрибьютером и донатера бабла в линукс.
Что даже после этого сам Линус написал, что ненависть к корпорации Microsoft - психическое отклонение.
NTFS ограниченная файловая система, на которой не возможен linux в режиме root partition.
Даааа, а Windows на ext зато как возможен, правда?
> Даааа, а Windows на ext зато как возможен, правда?э... ДА!
;-)Угадаешь с одной попытки, какой компании принадлежит работающий драйвер для этой и не только (еще позволяет чинить сдохшие прекрасные рейды от недокомпании seagate) целей?
В общем-то, и недорого...
Э… нет!
Собственно, речь не об ограниченности той или иной ФС, а о том, что они прибиты гвоздями к той или иной ОС.
> Э… нет!paragon software
https://www.paragon-software.com/home/linuxfs-windows/ наслаждайся.> Собственно, речь не об ограниченности той или иной ФС, а о том,
> что они прибиты гвоздями к той или иной ОС.в случае ext4 ВНЕЗАПНО выясняется (тут всплыло в комментах к статье очередного не особо грамотного но упорного гражданина несколько лет назад) круче - что она прибита гвоздями к архитектуре процессора.
И, соответственно, есть разные ext4, хотя ось создавшая их одна - systemd/linux, и они не читаются на чужих железках.(разумеется, у парагоновского драйвера нет этой проблемы - смешно, да? Ну что у винды нет проблем с чтением дисков, созданных другой виндой на других архитектурах, полагаю, очевидно.)
> соответственно, есть разные ext4, хотя ось создавшая их одна - systemd/linux, и они не читаются на чужих железках.Это юмор такой?
Это называется "человек что-то услышал про little и big endian и пытается втирать, что созданная на big endian ext4 не будет читаться на little endian и наоборот".Человек, конечно же, не в курсе, что в спеке ext4 прописано, что все поля хранятся в little endian и не зависят от архитектуры. И что, внезапно, с числами в любом endianness можно работать на любой архитектуре.
> Даааа, а Windows на ext зато как возможен, правда?На btrfs вполне возможен, хотя лично не проверял конечно.
> NTFS ограниченная файловая система, на которой не возможен linux в режиме root partition.надо же? На fat был возможен еще в 94м году - а ntfs - ограниченная ;)
И так у этих л@п4атых все - они нихрена не шарят в своей собственной системе.
Есть несколько дистрибутивов, которые можно установить на ntfs и они будут работать. По-моему даже установщик для убунты был. Насчёт fat не уверен, если только по принципу лайвсиди.
> Насчёт fat не уверен, если только по принципу лайвсиди.man filesystems /umsdos
Установщик был у sls, slackware до 3, по-моему, и, наверное, не только.
Оно в целом даже и работало, если не влезать в детали (манглинг был привязан, держись за стул - к позиции direntry - после копирования туда-сюда родными для fat средствами, разумеется, ломался)
P.S. туксера пишет что в последних версиях ntfs-3g проблема с unix permissions решена, причем, вроде как - понимаемым виндой способом, отдельным от acl, типа, пользуйтесь, не обляпайтесь.
"последние" - это 2016й год, разумеется.
https://help.ubuntu.com/community/Wubi
https://github.com/nikp123/ntfs-rootfs/wikiНе понятно зачем, опять же и там проблема будет с ACL и конвертацией прав и это не потому что NTFS ограниченная, а потому что в Linux устаревшая модель прав из прошлого, и линуксовское барахло нужно долго и упорно конвертить в нормальные ACL. Ой всё...
> NTFS ограниченная файловая система
Я хочу предоставить доступ на чтение, запись, выполнение файлов без возможности создания и удаления, чтения и изменения атрибутов и владельца для пользователей групп "Отдел маркетинга" и "Финансовый отдел", но только при условии, если атрибут города "l" в каталоге у них равен "Москва".
Ну давайте, сделайте мне это на вашей любимой ФС в Linux, а я посмотрю. Только чур локально, без Samba/NFS и без объявления новых групп в каталоге (вам туда доступа нет), а я посмотрю.
> Я хочу предоставить доступ на чтение, запись, выполнение файлов без возможности создания
> и удаления, чтения и изменения атрибутов и владельца для пользователей групп
> "Отдел маркетинга" и "Финансовый отдел", но только при условии, если атрибут
> города "l" в каталоге у них равен "Москва".Ну вот предоставишь ты такой доступ. А потом обломаешься, например, на том что банальный MSO хочет при открытии документа рядом с ним создать lock-файл, но не может, создание и удаление-то запретили. Ну и стоило ли городить огород?
А потом ещё захочешь внутри файла разным пользователям разграничить права. И тут окончательно выяснится, что однохренственно нужна какая-то специфичная для нужд конкретной конторы CMS на сервере, а не вот эти попытки сделать БД из ФС.
А так-то да, всё очень круто и звучит красиво, но на практике не применяется (а где попытались применить, ибо админам захотелось выпендриться, народ страдает).
Это всё, впрочем, не оправдывает всяких там вещающих про ограниченность.
> Ну и стоило ли городить огород?Я просто привел пример с потолка и ни про какое MSO даже и речи не идет, если не нужно создавать значит не нужно.
> А потом ещё захочешь внутри файла разным пользователям разграничить права. И тут окончательно выяснится, что однохренственно нужна какая-то специфичная для нужд конкретной конторы CMS на сервере, а не вот эти попытки сделать БД из ФС.
Ну что за фантазии...
> так-то да, всё очень круто и звучит красиво, но на практике не применяется (а где попытались применить, ибо админам захотелось выпендриться, народ страдает).
Очень много слов чтобы сказать "если мне не нужно, значит никому не нужно".
Речь идет о том, что NTFS ACL поддерживает ABAC и умеет хранить на себе сonditional expressions. ABAC - это Atribute Based Access Control. И никто вам просто так это на файлопомойку не включит. Если предприятие применяет ABAC вместо RBAC - это означает, что есть на то необходимость и это касается большого количества объектов инфраструктуры. ABAC предполагает написание политик безопасности как бизнес процессов и там начинается полный XACML. Такие вещи админы вообще не решают. У них одних банально компетенции не хватит так выпендрится.
Ну да ладно, попробуем проще (хе-хе, на самом деле сложнее). Хочу предоставить доступ к файлу, лежащему на файловом сервере, если пользователь "Вася Пупкин" запросил полный доступ с компа, находящегося в группе "SECUREPC", а с остальных должно быть только чтение.
Просто никто и не говорил, что подобное кому-то нужно в малом/среднем бизнесе, который непогнушается поставить Linux на рабочую станцию или файловый сервер. И нет на нем документов MSO, на этом файловом сервере. Весь документооборот в ECM, не в CMS и даже не в CMS, которые маскируются под ECM вроде битриксов несчастных.
> Не понятно зачем, опять же и там проблема будет с ACL и конвертацией прав и это не потому что
> NTFS ограниченная, а потому что в Linux устаревшая модель прав из прошлого,man setfacl, надеюсь, прочитан? Не то чтобы конвертация была возможна прозрачно, у posix acls другой набор параметров, но статическую табличку что во что - нарисовать вполне было бы можно.
Ну а что парагоновский драйвер не умеет (туксеровский умеет только в обратную сторону - да, в ntfs есть официальный режим совместимости с юниксами, и он его вроде бы обещался использовать - правда я таких версий не тестировал) - это проблема все же драйвера - он еще много чего не умеет, шифрования там, или потоков. Скажи спасибо что хоть файлы читает/пишет - и быстро.
> Только чур локально, без Samba/NFS и без объявления новых групп в каталоге (вам туда доступа нет)
в этом случае у нас, внезапно, нет и возможности узнать что-то там про "атрибут города"
У юникс-пользователей их не водится. В принцие, у windows пользователей их тоже не водится, это фича AD, а его, внезапно, может не быть.Да и явно избыточна подобная система для _локальных_ дисков.
В винде ее, собственно, тоже толком нет - принес я тебе _внешний_ диск - и...опачки, "локально" ты можешь, конечно, с правами админа разнести установленную там иерархию прав, но воспользоваться ей - не можешь (а если ты не админ - то и прочитать можешь только то что для Everyone, благо эти айдишки фиксированные. Причем никакими разумными средствами распространить права доступа на два несвязанных компьютера или синхронизировать sidы без общего (!) AD ты не можешь. В unix я могу доверить права доступа чужому админу - но не его пользователям - без необходимости связывать наши системы.)
> man setfacl, надеюсь, прочитан? Не то чтобы конвертация была возможна прозрачно, у posix acls другой набор параметров, но статическую табличку что во что - нарисовать вполне было бы можно.Ну я же так и сказал. Там не понятно, что с правами. POSIX ACL проще засунуть в кастомный атрибут (вроде так WSL1 и делает) и ничего не конвертить вовсе. Медленно это и есть риск сломать при переподключении такого диска в венду, табличка-то не даст взаимно однозначного соответствия.
> в этом случае у нас, внезапно, нет и возможности узнать что-то там про "атрибут города"
У юникс-пользователей их не водится. В принцие, у windows пользователей их тоже не водится, это фича AD, а его, внезапно, может не быть.
Когда каталога нет и доступа к файлу такому нет, если ты не локальный администратор. А так-то L объявлен в RFC2256. Он стандартный для LDAP к AD не привязан.> Да и явно избыточна подобная система для _локальных_ дисков.
Локальный понятие относительное. Когда я писал "чур локально, без Samba/NFS" речь как раз о том, чтобы не было _маппинга_, чтобы ФС умела это держать. И как может ФС такое без маппинга в NT ACL или хотя бы NFSv4 ACL?
> Причем никакими разумными средствами распространить права доступа на два несвязанных компьютера или синхронизировать sidы без общего (!) AD ты не можешь.
SID локального пользователя кодирует в себе идентификатор компьютера.
Во-первых, это не баг, а фича. Таковы дескрипторы безопасности венды. Сделано специально, чтобы при подключении диска к другому компьютеру идентификаторы не совпали. То есть то что ты считаешь фичей unix - просто историческая недоработка из прошлого. С тем же успехом можно просто локального пользователя выдать. Это разумнее. А если тебе не нравится что нужно вводить другой логин и пароль для доступа администратора к шаре, несмотря на то что он вошел в систему, ну дружок, для этого и придуман NTLM. Технология, кстати из той же эпохи, что и юниксовские дескрипторы безопасности.
Во-вторых, это не совсем правда, не обязательно AD. Потому что сто лет как есть MicrosoftAccount\username@email.com
LiveId это разумный метод для 2-х компов и ноута, но не в корпоративной среде.В-третьих ты не ограничен LiveID. Ты можешь заменить ее на свой сервис. Тебе нужно просто связать локального пользователя компьютера 1 с внешним пользователем системы, под управлением которой находится компьютер 2 с одной стороны. И зарегистрировать устройство как доверенное в удаленной системе с другой стороны. И никакого тебе AD, так ты добавляешь "учетную запись работы и учёбы".
Если у тебя 2 системы, то это не обязательно 2 AD в трасте, опять же. Там может быть и федерация.Но вот это всё далеко от темы с ФС... тут большинству народа такое не надо... Linux он не применяется в таких системах в виду ограниченности Linux в вопросах ACL и авторизации.
> Во-первых, это не баг, а фича. Таковы дескрипторы безопасности венды. Сделано специальнокогда диски были большие, а дискеты маленькие и их не имело смысла защищать - не нравится что вася может прочесть файлы для коли - дай ему отдельную.
Сейчас это вызывает определенные сложности, потому что тебе _могут_ принести портативный носитель большого объема, где уже очень желательно иметь какие-то ограничения доступа. И никакой разумной возможности заранее добавить к списку в acl "неместный" sid. (с шарингом в чужом домене тоже трудности)
> Во-вторых, это не совсем правда, не обязательно AD.
а если у одного из вас уже? И при этом, подчеркиваю, организации вообще никак не связанные.
> Linux он не применяется в таких системах в виду ограниченности Linux в вопросах ACL и
> авторизации.применяется, почему же - традиционным способом, включением его в AD. Ну или для самых отмороженных - через posix acls.
Что имеет некоторые нежелательные побочные эффекты - например, для всяких мелких специализированных применений, поскольку раздувает код.
Было в свое время весьма забавным приключением обнаружить, правда, не в линуксе, а в freebsd, что кастомно собранная система не загружаетсо, потому что zfs у нас (вот жеж блин) неработоспособна без, записывайте: krpc, acl_nfsv4 (проверить зависимости заранее нельзя, по тем же причинам - она не в ядре из-за копирайтов). При том что мне там обе они были как телеге мотор от камаза, и лошадь не утягивает, и нахрен бесполезен, и бабу с воза. И потом вытанцовывать в ограниченном пространстве, пытаясь впихать невпихyемое. Разумеется, опций сборки без них - не предусмотрено.
В линухе, подозреваю, все еще хуже, потому что у нас нет отдельного acl_nfsv4, и все fs переизобретают свои aclи с нуля, а потом еще и отдельно учатся мапить их в nfs. Но зато местами все еще сохранилась древняя магия отключения ненужно ifdef'ами.P.S. если что - glebius@ героицским трудом (как обычно, это не про кодинг, в основном, а про кодинг в coc.md было) заменил krpc, который там вообще нафиг не сдался, на огрызок xdr, но nfs aclи с нами навечно. К тому же mfc в 11, похоже, не будет, а в 13 скоро не будет работающей zfs.
> Cейчас это вызывает определенные сложности, потому что тебе _могут_ принести портативный носитель большого объема, где уже очень желательно иметь какие-то ограничения доступа.Вы смешиваете 2 никак не связанные задачи. Файловая система NTFS никогда не позиционировалась, как ФС для переносных устройств и это даже не обсуждается. Те, кто форматирует переносные устройства в NTFS, должны быть готовы к её логам, ACL и другим вещам, которые не нужны и даже вредны на переносных устройствах.
Касательно переключения жестких дисков из компа в комп - это вообще административная задача, а не пользовательская.Если мы говорим о сетевом доступе к данным, когда (не важно по какому протоколу) нужно аутентифицировать и авторизовать, то это другой разговор. Если мы даже забудем о проблемах случайного совпадения идентификаторов, и будем считать что все совпадения умышленные - это получается что там не аутентификация!!!
Аутентификация (в гуманитарном, насколько это возможно, смысле) предполагает олицетворение пользователя. 1. Учетные данные пользователя, предоставляемые для доступа должны быть связаны с человеком-пользователем, который их физически предоставляет.
ИЛИ!
2. Есть некая авторизация на делегирование учетных, когда _пользователь_ разрешил предоставить собственные учетные данные для предъявления третьей стороне.Не знаю, насколько вы знакомы с Auth(n/z)-темой, предположу что вы разбираетесь в протоколе OAuth2 :)
Первое в терминах OAuth2 - это Authorization Code, либо Implicit flow, а второе On-Behalf-Of flow.В случае маппинга sid никакой аутентификации не происходит, потому что нет олицетворения, вместо него идет привязка. В терминах OAuth2 это сравнимо с топологией Client Credentials flow. В котором предполагается авторизация сервиса1 (ПК1) на сервисе2 (ПК2). И вот авторизации сервиса 1 на сервисе 2, окромя разрешения админа (Admin Consent), я стесняюсь спросить, на чем основана-то? Как гарантии есть, что замапленный sid пользователя на ПК1, который на самом деле живет на ПК2 будет использоваться именно с ПК2, а не с ПК3?
> И никакой разумной возможности заранее добавить к списку в acl "неместный" sid. (с шарингом в чужом домене тоже трудности)
Я пытаюсь вам объяснить, что это не баг, это фича :)
Отсутствие аутентификации предполагает глубокие доверительные отношения между сервисом 1 и 2, потому что вместо аутентификации сервис 1 просто принимает учетные данные, потому что они пришли от сервиса 2, которому мы автоматически доверяем и пользователь тоже не обязательно знает об этом. Доверительные отношения такого типа должны быть защищены авторизацией. Далее пользователя необходимо авторизовать на ФС и вот только тут мы видим ACL.
> а если у одного из вас уже? И при этом, подчеркиваю, организации вообще никак не связанные.
Давайте сначала устраним противоречие из этого высказывания. Если у вас есть задача на предоставление доступа пользователю из организации 1 к ресурсу внутри организации 2, то по определению это либо связанные организации, либо _еще пока не_ связанные, и их надо связать. Факт предоставления доступа и есть та самая связь в гуманитарном смысле.
В техническом смысле отношения доверия могут быть самыми разными.
- 2 организации с двумя доменами (именно AD тут не принципиален от слова совсем)
Вариант 1: Kerberos Trust
Вариант 2: WS-Trust
Архитектуру траста или федерации, давайте оставим за скобками.- 1 организация имеет домен, а вторая нет
Вам нужно авторизовать недоменное устройство
Вариант 1: Kerberos (вогнать в домен)
Вариант 2: Привязать локального пользователя к внешнему/доменному и организовать доверие недоменного компьютера по TLS, выписав сертификат для недоменного компьютера, заверенный в организации, имеющей домен. Вот тут вам потребуется AD FS и AD DS с уровнем леса не ниже 2012 R2.
Вариант 3: Есть некий внешний сервер авторизации, которому доверяют оба. Тут уместны эти модные слова облачный, гибридный... И это совсем не обязательно AzureAD, вы сами такой можете настроить на открытых технологиях, благо тут нет никакого вендорлока, все протоколы исторически открытые.Если в вашей инфраструктуре есть такая вещь как безопасность у вас должна быть некая аутентификация и авторизация сервисов или устройств, а не только пользователей.
> применяется, почему же - традиционным способом, включением его в AD. Ну или для самых отмороженных - через posix acls.
Что касается присоединения к реалму кербероса, хоть в AD - это вполне рабочее решение, хоть в Linux с Kerberos не всё гладко, а что касается POSIX ACLs... ой всё... it's a practical joke :) Равно как и установка корня на NTFS. Вопрос уместности использования духовых язычковых инструментов представителями православного клириканства. Проще говоря, на хрена попу гармонь...
Нету в Linux нормальных ACL и точка.> zfs у нас (вот жеж блин) неработоспособна без, записывайте: krpc, acl_nfsv4
Наверное, потому что это была нормальная многофункциональная ФС...
> При том что мне там обе они были как телеге мотор от камаза, и лошадь не утягивает, и нахрен бесполезен, и бабу с воза.А. Вам нужны решения в стиле chmod 777 из 70-х? Вам с таким на Linux.
> В линухе, подозреваю, все еще хуже, потому что у нас нет отдельного acl_nfsv4, и все fs переизобретают свои aclи с нуля, а потом еще и отдельно учатся мапить их в nfs.
О чем я и говорю, несчастные люди.
Была попытка переделать сделав по аналогии с BSD, добавив модуль RichACLs, но task failed successfully.
Причем под улюлюканье баранов, которым "сложна". То ли дело недостандартизированный огрызок POSIX ACL. Им обычно тыкают в нос, типа вот есть у нас ACL на Linux. А на самом деле мрак и безблагодатность.
> Вы смешиваете 2 никак не связанные задачи.ну как то есть не связанные? Вот файлы, вот fs. Теперь выясняется, что вот тут играем, а вот тут - не играем, рыбу заворачивали.
Вон парагон (не будем уточнять каким способом) пособирал статистику - у него получилось что ntfs наиболее распространенная fs для именно переносимых накопителей. (логично, не ext4 жеж, которую хрен прочитаешь даже на соседней линуксной железяке не той породы)
> Как гарантии есть, что замапленный sid пользователя на ПК1, который на самом деле живет на ПК2
> будет использоваться именно с ПК2, а не с ПК3?я не дам. Вполне надежная гарантия - в этих вот рамках, то есть замки от сравнительно честных людей, а нечестные просто по голове дадут и диск отнимут. Вот в этот комп - втыкай, я с его админом давно знаком и ему и его решениям доверяю (в этих пределах). А вон тот я хз чей, в него не втыкай, там у тебя небось вирусни зоопарк давно, и претензии предъявлять некому.
Вполне себе реальный и вполне разумный use-case.
> Вам нужно авторизовать недоменное устройство
устройство - заметим, диск, а не компьютер где-то в сети (во втором случае нет никакой проблемы - авторизовываться будешь на нем _его_ а не местной учеткой - и уже будет неважно, "его" она локальная или из какого-то каталога _ему_ доступного _им_ взятая). Авторизовать его тоже можно - я посмотрел - ну, вроде, диск а не usb-поджигалка, сойдет.
> А. Вам нужны решения в стиле chmod 777 из 70-х? Вам с таким на Linux.
для той задачи - да, вполне устраивали, там нет надобности в более сложной авторизации, нет, linux там плохо подходил, со своими fs либо works as intended, либо на технологиях 80х годов прошлого века, либо оба сразу - не говоря уже о некоторых сложностях установки в ограниченном пространстве без возможности подключения своего носителя (фря так умеет, а линукс - упс), а докер в докере под докером там тоже не упали.
То есть я ничего не имею против дополнительной фичи с acl, но мне категорически не нравится когда она создает лишние грабли в том месте, где нахрен не уперлась.
> ну как то есть не связанные?ну вот как-то так. Внутреннее устройство на котором могут храниться конфиденциальные данные и установлена ОС и внешнее устройство для физической передачи данных имеют разные требования безопасности.
> я не дам. Вполне надежная гарантия - в этих вот рамках, то есть замки от сравнительно честных людей, а нечестные просто по голове дадут и диск отнимут
Воооот! Получается, что это как раз Admin Consent. Его наличие и отсутствие, и защита от нежелательного сетевого подключения вместо проверки авторизации. Мы говорим на разных языках, на самом деле. ACL не защищают от физических краж и локальных переключений дисков между компьютерами. Они разрешают или запрещают доступ аутентифицированным пользователям. В случае с маппингом аутентификации нет со всеми вытекающими последствиями. Почему? Потому что я уже писал об этом выше.
> устройство - заметим, диск, а не компьютер где-то в сети
нет не заметим. Вы по-прежнему смешиваете 2 разные задачи. Диск является устройством только если он переносной. Если он лакальный, шара или что угодно иное, то устройством является компьютер.
> То есть я ничего не имею против дополнительной фичи с acl, но мне категорически не нравится когда она создает лишние грабли в том месте, где нахрен не уперлась.
Времена изменились. Если раньше корпоративные ACL с наследованиями, условиями и правилами deny были частью мира кровавого ентерпрайза, то сейчас они пришли всюду, потому что облака адаптируют и реализовывают сложные модели прав. И нет, не потому что эти облака делают крупные ентерпрайзники и им это привычно. Вспомните с чего начался OAuth и чем он является OAuth2 сейчас. Возврата в прошлое не будет.
Несмотря на любые ACL вы всегда можете выдать локальных пользователей везде и всюду, чтобы решить проблему с требованием отношения доверия между устройствами. Это никогда не создавало лишних граблей. Или в чем там проблема?
> Это никогда не создавало лишних граблей. Или в чем там проблема?повторяю: проблема в том, что локальный пользователь отличный от меня, любимого - в сегодняшнем мире как раз - нонсенс, компьютеры - персональные. При этом носители данных большой емкости (_слишком_ большой чтоб придерживаться политики один носитель - один потребитель) - в изобилии.
Неперсональные у нас сервера, но тем _локальная_ fs с нагромождениями acl'ей как раз не требуется, вон у моего кластера вообще 600 на все файлы, потому что права доступа он на другом физическом юните хранит (правда, обратите внимание - и с кластерами в линуксе опа полная в этом плане, там даже пресловутые девять бит не везде правильно работают, чаще первые три только - то есть даже и от честных людей замков толком нет).
Иерархические acl'и актуальны в наши дни только сетевым и кластерным fs. А тем в общем-то необязательно их хранить там же где файлы, более того, чаще принята концепция физически раздельного хранения (mds/osd), винда и тут редкое исключение.
> Иерархические acl'и актуальны в наши дни только сетевым и кластерным fs.Ну не только в наши дни... оно и раньше было актуально в первую очередь для этой задачи. В локальной даже n-пользовательской системой в которой нет гуманитарного понятия "сетевой вход в систему" использование сложной иерархии ACL ничего не даёт, разве что кроме некоторого замедления доступа к диску.
И наоборот, если у вас есть 2 формы ACL, одна какая-то упрощенная на ФС, а другая отдельная для реализации сетевого функционала, то этот маппинг одного в другое - еще большее расточительство к ресурсам.
Такие ФС, как ZFS, NTFS или вот даже HFS+ подходят лучше для задач сетвевых и кластерных FS, чем любая обычная ext4, XFS и иже с ними. Это вопрос подбора ФС под свою задачу.
> повторяю: проблема в том, что локальный пользователь отличный от меня, любимого - в сегодняшнем мире как раз - нонсенс, компьютеры - персональные.
В этом случае наличие ФС со сложными ACL вам не нужна. Если вы используете NTFS то вам по-умолчанию предлагается использовать ряд элементарных упрощенных преднастроенных правил ACL, который драйвер дробит быстро и решительно. И вот тут и начинается разница в Linux "мама" - это чертовы 9 бит, а любой ACL - сбоку. И вместо того чтобы сделать отображение/представления ACL в 9 бит для обратной совместимости и прописать эти же правила, как упрощенные ACL (как в Macos) тут такого нагородили... и еще и обороняют своего уродца-инвалида, когда, на минуточку, в Solaris, MacOS все сделано вполне себе открытыми сановскими технологиями минимальным Sun RPC (OPC) / NFSv4 ACL, и то RPC там нужен-то только для узкого круга задач.
Я со своей стороны скажу. Если у вас есть гибкая файловая система с нормальными ACL И (обязательно И) у вас есть ядро/драйвер которое адекватно работает с этими ACL, подразделяя их на разные представления, чтобы на локальных задачах не задействовался сетевой функционал, на бескерберосных средах не действовали внешние SID, на без claim-овых средах не работали условные ACL с атрибутами - У вас (пользователя/администратора) всё будет хорошо и с функционалом и с производительностью.
Вариант из серии: мы выкатим огрызок, ой нам не хватаем сбоку прикрутим нестандартизированного уродца которого надо мапить в сетевые ACL через боль и потом будем с усёром доказывать что это круто и сделать нормальную систему не надо - это хрестоматийное поведение линуксоидов, которое я вижу повсеместно, аж до обсуждений истеричек lklm. Не думайте, что это opennet чем-то плохой, нет. Бараны повсюду, гляньте в комменты: https://lwn.net/Articles/788335/
> Неперсональные у нас сервера, но тем _локальная_ fs с нагромождениями acl'ей как раз не требуется, вон у моего кластера вообще 600 на все файлы, потому что права доступа он на другом физическом юните хранит (правда, обратите внимание - и с кластерами в линуксе опа полная в этом плане, там даже пресловутые девять бит не везде правильно работают, чаще первые три только - то есть даже и от честных людей замков толком нет).
Если вы под кластером имеете в виду традиционный кластер, когда у вас есть, HA/LB, ноды, хартбит, менеджмент ресурсов и кластерное хранилище и обсуждаете права именно на пресловутом "кластерном хранилище" в традиционном смысле, то тогда я могу понять почему вы там что-то мапили по sid-ам, потому что адекватного иного способа вроде бы нет в unix. А реальные ACL приложения у вас там хранит, какая-то база, небось. Тогда все понятно.
В мире MS просто все то же самое только лишь с точностью до SID, которые традиционно нельзя брать откуда попало. Там просто создается керберос-учетка для делегирования внешних пользователей на ноды. Использовать этот подход на *nix ничто не запрещает. Для таких кластеров NTFS и SMB имеют специальный упрощенный профиль для работы с ACL и метаданными (писал выше про такие приемы). И! Если вы создаете такой кластер в котором у вас почему-то нельзя использовать Kerberos, то вы используете вариант с взаимным доверием SSL-сертификатам всех нод этого кластера. И чисто технически у вас нет возможности организовать там вменяемую аутентификацию пользователя (нет кербероса и ничего для олицетворения), если делаете кластеризованный файловый сервер. Безопасность будет снижена, поэтому шарить файло оттуда людям не рекомендуют, только в доверенные приложения. То есть методика достижения цели другая, но архитектура будет ну практически 101.
Вам только нужно проставить им правильные DNS-суффиксы. Задача специфична для Windows, который по традиции имеет треклятую службу IBM NetBT по умолчанию, вместо нормальных имен хостов. В итоге вы получите кластер в недоменной или мультидоменной среде. НО! Это нетипичная задача. Традиционный кластер, предполагается использовать в одной группе префиксов сетей и в большинстве случаев эти префиксы находятся под управлением одного керберос-реалма. Гибридные-облачные среды, когда одна нода где-то там далеко в облаках федерируются иначе. И да, я тут пишу про взаимное доверие по SSL между нодами и DNS, как о нормальном решении, специально забывая о косорылых:
+ LocalAccountTokenFilterPolicy=1,
+ NTLM-Only Fresh Credentials Delegation
+ CredSSP Trusted Hosts
которые точно также дадут локальным админам (но не пользователям) возможность рулить всем-всем-всем, надо только понасоздавать пользователей с одними и теми же именами :) ничего не напоминает?
Но, в этой ситуации, у вас полный NTLM и IBM NetBIOS примечательно, что это технологии той же эпохи, что и unix sid и девятибитные "ACL". И несмотря на это, у NTLMv2 безопасность будет выше, чем у вашего решения.
Однако, это такая косорылая жесть, что лучше этим не пользоваться. Я не хочу вдаваться в детали реализации на таких технологиях, чтобы не приведи Кришна, кто-то не додумался, прочитав, воспользоваться этим "решением". Ирония в том, что в мире Linux такие подходы по безопасности - это норма. Что только не придумают, лишь бы керберосом не пользоваться.А про именно Linux в вопросах традиционной кластеризации в отличии от других unix ОС я ничего сказать не могу. Никогда ему не доверял такие задачи. Особенно инфраструктурные кластеризации, наслушавшись от знакомых и насмотревшись на их боль про падающие и разваливающиеся CEPH-и. Тот случай, когда NTFS + SMB + S2D надежнее.
Баблишки и они и все эти столманы готовы принимать хоть у черта
То есть они принимают бабло с лицемерной улыбкой, а сами потом голосят на opennet, как хорошо бы было, если бы Майкрософт загнулась?Какое же лицемерие. Ну допустим теоретически Майкрософт, redhat и другие корпорации загнуться.
Кто будет разрабатывать линукс и платить Линусу ЗП? Эти голосящие, линаксоиды?Да они сейчас копейку удавятся и не вложат в линукс ни цента.
А тем более не будут помогать с разработкой.
Ведь они просто лицемеры и больше ни на что не способны.
> То есть они принимают бабло с лицемерной улыбкой, а сами потом голосят
> на opennet, как хорошо бы было, если бы Майкрософт загнулась?
> Какое же лицемерие. Ну допустим теоретически Майкрософт, redhat и другие корпорации загнуться.
> Кто будет разрабатывать линукс и платить Линусу ЗП? Эти голосящие, линаксоиды?
> Да они сейчас копейку удавятся и не вложат в линукс ни цента.
> А тем более не будут помогать с разработкой.
> Ведь они просто лицемеры и больше ни на что не способны.А тут многие на опенннете выступают, что зарплата программиста, мол, неоправданно завшена. А столман часто говорит, что любимым делом можно и забесплатно заниматься
И вместо еды ногти грызть на ногах? :)
> И вместо еды ногти грызть на ногах? :)То-то он довольно упитан ;)
Одни загнуться, другие восстанут, а линух нужен везде и всем. Так, шта Торвальдс без куска хлеба не помрёт;)
А чего тебя так болезненно задевает, если линуксоиды то софт виндовый в Wine запускают, то включают в ядро поддержку проприетарых ФС открытым кодом? С таким психическим надломом нельзя жить. Не ровён час, суицидом можешь закончить. Обратись за помощью к психиатру.
> А чего тебя так болезненно задевает, если линуксоиды то софт виндовый в
> Wine запускают, то включают в ядро поддержку проприетарых ФС открытым кодом?
> С таким психическим надломом нельзя жить. Не ровён час, суицидом можешь
> закончить. Обратись за помощью к психиатру.Психиатор не поймет эти страдания, открытое-закрытое, как и большинство населения
Да психиатру это ни к чему. Ему диагностировать какое-то глубокое депрессивное расстройство у того господина.
Ого, вы и по большинству населения специалист?
> Ого, вы и по большинству населения специалист?Достаточно опросить представителя этого населения, вот некто дмитрий медведев на эту тему уже высказывался
Это не лицемерие, это попытка жить в более-менее реальном мире, где 90% десктопа на винде. Идеалисты все на BSD сидят.
А про "маздай" и "майкрософт должна умереть" - с этим вам в 90-е, к тогдашним школьникам, да и отношение такое в себе MS вполне заслужила своей политикой. Сейчас вроде исправляются, но смотрят на нее все равно очень насторожено.
Помню 90% GPS популярных приемо-передатчиков было на Nokia )
А как оно работает с ACL? Полную поддержку RichACL в ядре так и не приняли, а кастрированная Posix ACL никуда не годится для маппинга прав из NTFS
Тоже интересно через какой они виртуальный костыль это прокинули, подобно ZFS...
Тоже плюсую. Вендовый ACL божественен по сравнению с онтопиком.
Да, особенно хороши скрытые файлы. Вирусы одобряют.
Скрытые от кого? Поставь галочку "Показывать скрытые файлы", и они превратятся в открытые. И опять же, это проблема проводника, но никак не самой ОС. Скрытые файлы есть и в линуксе, те самые, которые с точки начинаются.
Там файлы прячутся в журнале по-моему, ну и https://en.wikipedia.org/wiki/Fork_(file_system)
Интересно, кто такой умный тебя заплюсовал, а меня заминусил (он видимо не один такой, хаха).
Жуткое удолбище, кстати, работать без shopt -s dotglob по умолчанию - то ещё извращение.
> Да, особенно хороши скрытые файлы. Вирусы одобряют.Как скрытые файлы относятся к ACL?
Скрытые файлы венды часть вендового acl, как и стримы. Слишком много сомнительных функций у нтфс.
> Скрытые файлы венды часть вендового acl, как и стримы. Слишком много сомнительных
> функций у нтфс.
+nohidden Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN)
+ attribute will not be shown under Linux.
Hidden files никогда не были часть видового acl. Это все равно что утверждать что скрытые файлы в линаксе (точка в начале имени файла) часть posix acl
Да не те скрытые файлы, алло. До чего же тупые вендузятники: не знают вопроса, но делают вид, что во всём разбираются лучше всех. Я кажется понимаю за что их ламаками прозвали. Те, про которые вы говорите, отличаются условным аттрибутом -- битом или байтом в имени.
Я по другим тредам догадался... Ты просто не знаешь базовой терминологии, не понимаешь что множественные потоки данных не является файлами и не понимаешь что они являются одним из ключевых преимуществ ntfs...
И таки да - они не являются частью winacl, а просто механизмом для ее реализации. Кстати - их же можно использовать для реализации posix acl в ntfs... И не только их, а много чего ещё. Что в случае линуксовых ФС потребует адового костылинга.
Ну тут ты уже начинаешь ментальную эквилибристику. Зачем, для чего? Я ведь даже сказал о том, где все эти интересные и жутко полезные вещи находятся -- в журнале. При чём тут файлы? Почему вы всегда считаете собеседника идиотом, а себя видите исключительно на белом коне?
Ну извините - если человек не может связно изложить свои мысли, не знает базовой терминологии и не понимает очевидных вещей, то как к нему относиться?
Примеров использования множественных потоков данных - вагон и маленькая тележка. От реализации acl до того что всячечкие извращения типа elf/coff становятся ненужными ибо быстрей и проще реализуются через потоки данных.
Я столкнулся с тем, что NTFS-ная ACL оказалась не пригодной для руления UNIX-правами. Как-то коллега притащил ноут с установленной Ubuntu с жалобой, что он не может писать в хомяк юзера. Смотрю, а Бунта как-то умудрилать установиться на, существовавший у него, виндовый раздел NTFS. Ставлю право записи владельцу на /home/username. Ошибок не сообщается, но ничего и не меняется.
Установилась куда сказали.
Дебилы предсказуемы в своей непредсказуемости. Это в интсалере убунты не предусмотрено. Как и влюбом другом софте.
А что сейчас уже и так можно?! о_О
> А как оно работает с ACL? Полную поддержку RichACL в ядре так
> и не приняли, а кастрированная Posix ACL никуда не годится для
> маппинга прав из NTFSХранит Posix ACL в :$EA :)
Это не ЕА, а альтернативные потоки данных.
Это намёк, что "обычные" данные файла хранятся в безымянном ADS типа :$DATA ? https://docs.microsoft.com/en-us/windows/win32/fileio/file-s...
Ну типа как с vlan - первый особенный.😆 Плоская сеть, не разбитая на vlan-ы на самом деле находится в vlan 1.
Парагону уважение!
Единственный лайв, который реально смог сделать Full-drive backup dual-boot-системы с 5ю разделами даже не смотря на то что "не должен был в этой версии читать не-windows-разделы".
А тебе не уважение за прогиб перед проприетарщиками.
Что ж поделать, если опенсорс не осилил.
что, уже таки dd(1) в самом деле не видело диска?
> что, уже таки dd(1) в самом деле не видело диска?что, уже таки в самом деле мусор с "пустого" места врхивируют в бэкап?
>> что, уже таки dd(1) в самом деле не видело диска?
> что, уже таки в самом деле мусор с "пустого" места врхивируют в
> бэкап?cp /dev/устройство файл, потом архивируете
> cp /dev/устройство файл, потом архивируетеТы хоть сам понял, что ответил? :'D
Нтфс 3г мало того что тормозная, так и не поддерживает хардлинки из явного. Если хотя бы тормоза уберут, уже норм.
так и не поддерживает хардлинки из явного.ЩИТО? А что-же делает тогда 'fsutil hardlink create' в NTFS?
https://www.tuxera.com/community/ntfs-3g-faq/#unsupreparse
>GPL2-onlyДа, хорошая лицензия. Столлман будет доволен
В случае патчей в ядро выбор не велик :)
Не совсем, он бы предпочёл GPLv3+.
Очень здорово.Пользуюсь Paragon NTFS. Он быстрее. Например, когда я открываю директорию с кучей файлов (две тысячи), файловый менеджер показывает файлы с Paragon NTFS раньше, чем с NTFS-3G.
Кстати, хотел им в техподдержку написать об ошибках сборки с не дистрибутивным кастомным ядром. Но всё забывал. Спасибо что напомнили.
Ребят, а есть патчи на GParted, чтобы для разметки использовались не ntfsprogs, а программы из коммерческой версии Paragon NTFS?
> Пользуюсь Paragon NTFS.краденой, я надеюсь?
> Ребят, а есть патчи на GParted
а, точно, краденой. Иначе бы ты этот вопрос техподдержке задал, а не в вентиляционную трубу орал.
>> Пользуюсь Paragon NTFS.
> краденой, я надеюсь?Надейся.
>> Ребят, а есть патчи на GParted
> а, точно, краденой. Иначе бы ты этот вопрос техподдержке задал, а не в вентиляционную трубу орал.Мне как-то неловко просить техподдержку добавить что-то в GParted, учитывая что последний это клон парагоновской же Partition Magic. Это как просить Майкрософт добавить в LibreOffice поддержку VBA.
> Надейся. Да как-то неловко просить техподдержку добавить что-то в GPartedучитывая что патч на одну строчку, а платить за partition magic (кто кого клон еще вопрос) ты явно не планируешь?
> Это как просить Майкрософт добавить в LibreOffice поддержку VBA.
это как просить об этом microsoft сразу после того как она уже добавила бы туда открытую реализацию visio (и была бы послана лесом потому что "кода что-то слишком много, порежьте помельче, мне в экран нивлизает")
то есть, собственно, почему бы и нет?
GParted версии 0.1 появился в 2007 году. В этот момент Partition Magic был версии 8.0.
Ну окей, спрошу.
А сейчас как разметка и форматирование проходят, какими средствами? Неужели виндой?
> А сейчас как разметка и форматирование проходят, какими средствами?mkntfs(8) - Create an NTFS filesystem.
(если не хотеть от нее странного - в общем-то даже и работает)
Начнём с того, что Partition Magic — это Symantec.
Вообще-то PowerQuest.
partition magic не имел никакого отношения к парагону. его писал powerquest, в 2003 году symantec их купил и закопал.у парагона есть partition manager, который вроде бы начался в том же 94 году, как и partition magic.
Есть патч для тебя.
Лицензия, лицензия.. Когда уже РеактОС будет готова? А то ну не понимают юзеры линуксовых прог. Им подавай те, к чему они на Винде привыкли. Только бесплатно и без оплаты. Фотошопы там, корел Дравы.. А Линукс это не винда..
> Лицензия, лицензия.. Когда уже РеактОС будет готова? А то ну не понимают
> юзеры линуксовых прог. Им подавай те, к чему они на Винде
> привыкли. Только бесплатно и без оплаты. Фотошопы там, корел Дравы.. А
> Линукс это не винда..Корел еще жив?
> Корел еще жив?Более чем. Большую часть этикеток, плакатов и прочей векторной лабуды в нём делают.
>ну не понимают юзеры линуксовых прогТак многие вендоюзеры понимают только фконтактики, да мордокнижки. Так какая им разница, где Firefox запущен: в Винде или в Linux?
А другим многим вендоюзерам тем не менее нужны виндовые программы.
Какие, например? Я ни одной такой не знаю.
Ну, видимо, вы из тех, кому достаточно контакта и мордокниги.
> Ну, видимо, вы из тех, кому достаточно контакта и мордокниги.Т.е. вы используете софт венды? Что-то подсказывает, что вы сами из той категории.
Прошивальшики для телефонов и флэшек есть на линуксе? Victoria есть на линуксе? WDMarvel есть на линуксе? Мир вендософта не ограничивается фотошопом и офисом.
Это не софт венды, это софт собранный для венды. Чаще всего легаси.
> Это не софт венды, это софт собранный для венды.Нет, это демагогия.
> Чаще всего легаси.Да-да, а теперь-то все пишут и под винду, и под линукс.
Victoria 5.28 HDD/SSD
Что нового в версии 5.28 (14 апреля 2020г)Легаси, да.
Именно что легаси, написали 30 лет назад и тянут с тех пор -- выкинуть жалко. Нужно учитывать тогдашние реалии.
как раз в данный момент Victoria лечит диск на втором компе. Вижу по логам, что вылечит нормально - и данные удастся снять, и диск ещё будет некоторое время работать, пускай и с провалами по скорости в том месте, и с риском.
Именно такой софт и имеет значение. Люди работают, понимаете? Не дрочат на столлмана.
flashtool успешно на линуксе работает, причём без гемора с драйверами
Внезапно чипсеты для телефонов не ограничиваются медиатеками.
для тебя это может быть новостью, но в винде есть бесплатный софт и он на много удобнее ваших ss htop top iftop из 80ых
NTFS в 2020
Ой вей
XFS(1994) в 2020 ок?
Не, не ок - до сих пор крэшится на ровном месте.
Хотите бэктрейс - могу поделиться.И да, кто-нибудь такое на нормальном железе и исправной fs от ntfs3-g видел?
> Не, не ок - до сих пор крэшится на ровном месте.
> Хотите бэктрейс - могу поделиться.Хочу, конечно, так что повторно прошу поделиться.
kernel: Workqueue: xfs-cil/dm-2 xlog_cil_push_work [xfs]
kernel: [<ffffffffc053fc7d>] xlog_state_get_iclog_space+0x10d/0x320 [xfs]
kernel: [<ffffffffc0540369>] xlog_write+0x1a9/0x750 [xfs]
kernel: [<ffffffffc0542138>] xlog_cil_push+0x2a8/0x430 [xfs]
kernel: [<ffffffffc05422d5>] xlog_cil_push_work+0x15/0x20 [xfs]
kernel: Workqueue: xfs-sync/dm-2 xfs_log_worker [xfs]
kernel: [<ffffffffc0542b0a>] xlog_cil_force_lsn+0x8a/0x210 [xfs]
kernel: [<ffffffffc0540a85>] _xfs_log_force+0x85/0x2c0 [xfs]
kernel: [<ffffffffc0540d66>] ? xfs_log_worker+0x36/0x100 [xfs]
kernel: [<ffffffffc0540cec>] xfs_log_force+0x2c/0x70 [xfs]
kernel: [<ffffffffc0540d66>] xfs_log_worker+0x36/0x100 [xfs]
kernel: Workqueue: xfs-cil/dm-2 xlog_cil_push_work [xfs]
kernel: [<ffffffffc053fc7d>] xlog_state_get_iclog_space+0x10d/0x320 [xfs]
kernel: [<ffffffffc0540369>] xlog_write+0x1a9/0x750 [xfs]
kernel: [<ffffffffc0542138>] xlog_cil_push+0x2a8/0x430 [xfs]
kernel: [<ffffffffc05422d5>] xlog_cil_push_work+0x15/0x20 [xfs]
kernel: Workqueue: xfs-sync/dm-2 xfs_log_worker [xfs]
kernel: [<ffffffffc0542b0a>] xlog_cil_force_lsn+0x8a/0x210 [xfs]
kernel: [<ffffffffc0540a85>] _xfs_log_force+0x85/0x2c0 [xfs]
kernel: [<ffffffffc0540d66>] ? xfs_log_worker+0x36/0x100 [xfs]
kernel: [<ffffffffc0540cec>] xfs_log_force+0x2c/0x70 [xfs]
kernel: [<ffffffffc0540d66>] xfs_log_worker+0x36/0x100 [xfs]
kernel: Workqueue: xfs-cil/dm-2 xlog_cil_push_work [xfs]
kernel: [<ffffffffc053fc7d>] xlog_state_get_iclog_space+0x10d/0x320 [xfs]
kernel: [<ffffffffc0540369>] xlog_write+0x1a9/0x750 [xfs]
kernel: [<ffffffffc0542138>] xlog_cil_push+0x2a8/0x430 [xfs]
kernel: [<ffffffffc05422d5>] xlog_cil_push_work+0x15/0x20 [xfs]
kernel: Workqueue: xfs-sync/dm-2 xfs_log_worker [xfs]
kernel: [<ffffffffc0542b0a>] xlog_cil_force_lsn+0x8a/0x210 [xfs]
kernel: [<ffffffffc0540a85>] _xfs_log_force+0x85/0x2c0 [xfs]
kernel: [<ffffffffc0540d66>] ? xfs_log_worker+0x36/0x100 [xfs]
kernel: [<ffffffffc0540cec>] xfs_log_force+0x2c/0x70 [xfs]
kernel: [<ffffffffc0540d66>] xfs_log_worker+0x36/0x100 [xfs]
kernel: Workqueue: xfs-cil/dm-2 xlog_cil_push_work [xfs]
kernel: [<ffffffffc053fc7d>] xlog_state_get_iclog_space+0x10d/0x320 [xfs]
kernel: [<ffffffffc0540369>] xlog_write+0x1a9/0x750 [xfs]
kernel: [<ffffffffc0542138>] xlog_cil_push+0x2a8/0x430 [xfs]
kernel: [<ffffffffc05422d5>] xlog_cil_push_work+0x15/0x20 [xfs]
kernel: Workqueue: xfs-sync/dm-2 xfs_log_worker [xfs]
kernel: [<ffffffffc0542b0a>] xlog_cil_force_lsn+0x8a/0x210 [xfs]
kernel: [<ffffffffc0540a85>] _xfs_log_force+0x85/0x2c0 [xfs]
kernel: [<ffffffffc0540d66>] ? xfs_log_worker+0x36/0x100 [xfs]
kernel: [<ffffffffc0540cec>] xfs_log_force+0x2c/0x70 [xfs]
kernel: [<ffffffffc0540d66>] xfs_log_worker+0x36/0x100 [xfs]
kernel: Workqueue: xfs-cil/dm-2 xlog_cil_push_work [xfs]
kernel: [<ffffffffc053fc7d>] xlog_state_get_iclog_space+0x10d/0x320 [xfs]
kernel: [<ffffffffc0540369>] xlog_write+0x1a9/0x750 [xfs]
kernel: [<ffffffffc0542138>] xlog_cil_push+0x2a8/0x430 [xfs]
kernel: [<ffffffffc05422d5>] xlog_cil_push_work+0x15/0x20 [xfs]
kernel: Workqueue: xfs-sync/dm-2 xfs_log_worker [xfs]
kernel: [<ffffffffc0542b0a>] xlog_cil_force_lsn+0x8a/0x210 [xfs]
kernel: [<ffffffffc0540a85>] _xfs_log_force+0x85/0x2c0 [xfs]
kernel: [<ffffffffc0540d66>] ? xfs_log_worker+0x36/0x100 [xfs]
kernel: [<ffffffffc0540cec>] xfs_log_force+0x2c/0x70 [xfs]
kernel: [<ffffffffc0540d66>] xfs_log_worker+0x36/0x100 [xfs]
ну и вот хрен его знает, какую пользу можно извлечь из этой информации. "шитота пошло нетак" - ну, я, в общем, даже и без этих логов догадался, что если распаковка (ну да, ну да, 31G, а что, нельзя было?) архива зависла и даже на ctrl-c не реагирует, оно явное "не так".
> ну и вот хрен его знает, какую пользу можно извлечь из этой
> информации. "шитота пошло нетак" - ну, я, в общем, даже и
> без этих логов догадался, что если распаковка (ну да, ну да,
> 31G, а что, нельзя было?) архива зависла и даже на ctrl-c
> не реагирует, оно явное "не так".Спасибо, погляжу. Пожалуй, ещё версию ядра очень не помешало бы.
dm-2, кстати, из чего состоит? Чисто multipath том от полки или какой-нибудь LV?
3.10.0-957.el7.x86_64 - oracle, не родная (впрочем, при нынешней-то борьбе за воспроизводимость ненужно, полагаю, совпадает побитно)dm2, который развалился, да, обычный dm-multipath
Причем это лезвие среди пачки других, которые чувствуют себя вполне хорошо (разумеется, там vmware или винда, да и тут она же была и тоже не плакала)
Скорее всего ларчик открывается как-нибудь просто - хранилка в очередной раз слегка тормознула, все кроме xfs это переварили даже не заметив, а у нее какой-то лок продержался чуть дольше чем предполагали авторы.
(и падения 2009го года скорее всего ровно по тем же причинам, там были дешевые и дерьмовые диски на дешевых и дерьмовых контроллерах)
> Скорее всего ларчик открывается как-нибудь просто - хранилка в очередной раз слегка
> тормознула, все кроме xfs это переварили даже не заметив, а у
> нее какой-то лок продержался чуть дольше чем предполагали авторы.
> (и падения 2009го года скорее всего ровно по тем же причинам, там
> были дешевые и дерьмовые диски на дешевых и дерьмовых контроллерах)Беда в том, что я и на не очень-то «дешёвых и дерьмовых» контроллерах и дисках иногда вижу эпичные затупы (но это именно очень сильный тупняк, не крэш). Пожалуй, любую ФС получалось практически положить кучей мелких записей или read-modify-write (например, удаление кучи мелких файлов в это превращается), но:
а) есть разница в поведении в других ситуациях, т.е. если этот сценарий плох у всех, нужно ценить и выбирать по поведению в других
б) в сценарии укладывания мелкими обращениями тоже есть разница между ФС, т.е. ложатся все, но не одинаково быстро и не одинаково фатально.В итоге приходится жить в ситуации «выбираю его не потому что лучше всех, а потому что остальные ещё хуже».
На ровном месте? XFS? А ты шутник
> На ровном месте? XFS? А ты шутникну не было у бабы хлопот - поставила себе xfs, ага.
Там надо было платформу под очень-очень ентер-прайсный софт, поэтому поставил ту конфигурацию, которую, как мне казалось, от нас ждали, хотя требования такого и не было, только пожелания.
А вот в 2009-м наелись мы той xfs от души (ha/hl система на ~500 "недорогих" тазиках, понятное дело, у тебя каждый день какой-нибудь крэшится). Я-то по наивности поверил, что с того момента rhbm эти детские баги поисправляла.
Голословно
> Хотите бэктрейс - могу поделиться.да было бы неплохо посмотреть, с ментейнерами связывались?
А смысл? Во-первых, писать на деревню-дедушке бесполезно.
Во-вторых не думаю что это мое уникальное везение - тем более что я насмотрелся того же самого десять лет назад на совсем другом железе.В-третьих для аргументированного предъявления проблемы майнтейнеру одного бэктрейса явно недостаточно, а собирать единственноправильную версию ядра и пытаться на ней воспроизводить - это время и деньги, а у меня ни того, ни другого (я в общем не особо заинтересован в улучшениях xfs, пора бы ей уже на покой)
> XFS(1994) в 2020 ок?Интересные доработки там происходили гораздо позже 1994. И да, результат очень даже ОК.
Не в упрек XFS она очень даже годная разработка SGI, я про тупую критику NTFS тип старая... ЩИТО?
Вот только xfs 2020 и 1994 мягко говоря не одно и тоже.
вы даже не откроете его на ядре 2.6.
Фичи добавляли, а концептуально не меняли как в той же NTFS возьми 1993 года и 2001
Да, XFS до сих пор лучшая для хостинга, скажем, кластеров того же Слона.
ну извенииите, открывать наш драйвер refs мы пока не совсем еще почти окончательно готовы.(да, он у нас есть, да, разумеется in-kernel, да, работающий, и быстро. Да, microsoft в курсе и претензий вам не предъявит, а мы - уже договорились)
Видимо не соответствует стандартам качества, иначе бы уже подсуетились.
> NTFS
> JBD (Journaling block device)Некрофилия. Журналирование на выделенном блочным устройством - это даже не вчерашний день.
Paragon Software - не нужно, NTSF - не нужно. Все четко и кратко.
Бесполезные комментаторы не нужны.
Круто. Paragon одна из немногих отечественных компаний за деятельность которой не стыдно. Мало говорит, а то что делает отличается качеством, несмотря на сложную выбранную область деятельности.
немного статистики по коду патча, 16 позиций:
https://pastebin.com/Eykvb927и первые 16 позиций ядра 3.16, для сравнения:
https://pastebin.com/tGmyUcus
Драйвер использует определённые ядром типы данных и макросы, корректнее сравнивать с аналогами, драйверами других ФС.
я хочу сказать, это не просто большое, а огромное количество goto; на 2 месте из всех ключевых слов си; и кому-то это придётся рецензировать
А Вы не считали, каков процент "goto out;" от всех goto?
indian hakka noodles
Без реализации chkdsk бесполезно - побъётся, а чинить нечем, кроме самой винды, будет потеря данных.
> Без реализации chkdsk бесполезноу нас - есть!
(вообще-то у tuxera тоже есть, но тот что шва6одный - очень так себе: "and make Windows perform a thorough check next time it boots")
> шва6одныйпочему тебе не стыдно?
Может на сей раз ЭТО ОН?!
Костя, который Комаров вопрос к тебе - а реализация альтернативных потоков есть? Че то из новости следует что нету.
Хваленый парагон не смог нормально оформить патчи, лишний раз позорясь говнокодом.
> err = -ENOMEM;
> goto out;goto жив и люди умеют им пользоваться, что радует.
Так и есть. В goto самом по себе нет ничего плохого.
Он ничем не хуже break, continue и return.
Для C (собственно сабж) вполне.
Для C++ всё же странно выглядит.
Это стандартный паттерн обработки ошибок в Си, используется много где. И не от хорошей жизни, а от убогости языка.
Первая современная и рабочая ФС в линаксе. Заметно.
Нет, не серьезно - ext4 не современная и много чего не умеет, xfs - лучше, но вообщем аналогично - много чего не умеет, btrfs - супер, но гарантирует потерю данных...
Набор штампов мало относящихся к реальности.
Это - факты. Из ныне живых ФС в линаксе наиболее современна и интересна btrfs. Но она до сих пор нестабильна. А всяческие ZFS on Linux я не готов считать полноценными реализациями, извините
> Это - факты. Из ныне живых ФС в линаксе наиболее современна и
> интересна btrfs. Но она до сих пор нестабильна. А всяческие ZFS
> on Linux я не готов считать полноценными реализациями, извинитеНе-не-не, так не пойдёт. Скажи прямо и честно: чего такого из коробки умеет NTFS, чего при этом не умеет XFS? Вот это написанное выше «много чего не умеет» слишком абстрактно для фактов, давай конкретнее, пожалуйста.
Только, чур, не формальным образом по табличке с wiki с перечислением всяких никем не используемых фич (и не доведённых до ума, кстати), а по своему субъективному, но реальному опыту.
> Не-не-не, так не пойдёт. Скажи прямо и честно: чего такого из коробки умеет NTFS, чего при этом
> не умеет XFS?не крэшиться под нагрузкой от непонятных причин, например.
>> Не-не-не, так не пойдёт. Скажи прямо и честно: чего такого из коробки умеет NTFS, чего при этом не умеет XFS?
> не крэшиться под нагрузкой от непонятных причин, например.А вот всё-таки не надо переоценивать распространённость своего случая. Единственный случай, когда у меня XFS именно крэшился (причём, в итоге даже воспроизводимо и, сюрприз, без потери данных), в итоге раскопок привёл к обнаружению того что в ядре было кое-что поломано в работе с определёнными мьютексами (и проявлялось это не совсем в дефолтной конфигурации ядра, а только при сборке без SMP). А код XFS тут вообще ни при чём оказался, просто он был чутка более параноидален в плане проверок, чем остальной. В приведённом выше стеке тоже на какой-то дедлок нелепый похоже.
Подробности за давностью лет надо вспоминать и откапывать, но сам факт: падение якобы в коде XFS, но анализ кода и отладка показали что причина не в нём, а в том что в ядре кое-что поломалось рядом. Такие вот грустные вещи в Linux встречаются порой. Впрочем, у NT таких случаев тоже хватает, разве что зоопарка конфигураций сборки нету, впрочем, это с лихвой компенсируется сложностью legacy кода для обратной совместимости, да (поту)сторонними драйверами от всяких Ляо.
> А код XFS тут вообще ни при чём оказался, просто он был чутка более параноидален в плане
> проверок, чем остальной.ну вот кому от этого щастье?
Но у нас fs периодически таки разваливалась совсем (то что я показал - самопочинилось при перезагрузке, но это единичный случай, такие тогда тоже бывали, гораздо чаще чем насмерть ломалось, просто не гарантированно). Причем на стандартном ведре (в немного нестандартных позах, но все через штатные параметры). Перешли на ext4 (безжурнальную там где на нее изобильно гадило логами) - проблема рассосалась сама собой, поэтому никто особо в ней и не копался.
Ну и ntfs3g я пользователь прямо с момента ее появления - и (кроме жора cpu в некоторых клинических случаях, что простительно) тоже плохого про нее не скажу. То есть, собственно, ценные данные предпочитаю хранить именно в ней.
> А вот всё-таки не надо переоценивать распространённость своего случаяНу вот ещё:
https://bugzilla.kernel.org/show_bug.cgi?id=201331
Притом оно у меня воспроизводилось, но убедить разработчиков в том, что нужно разбираться, я не смог (а самому не хватило квалификации/времени).
Про странности конфигурации разработчики правильно отметили (ИМХО, ext4 нещадно злоупотребляет отложенной записью, поэтому с ним действительно такие проблемы не очень заметны, до определённого несчастливого момента, конечно), но разбираться и правда надо.Тут в свежем ядре KCSAN обещают, интересно, что он позволит накопать в этом направлении.
> Про странности конфигурации разработчики правильно отметилиа что notabug - тоже правильно? ;-) Кого-то еще удивляет, почему я люблю ntfs, желательно - в оригинале?
То есть конфигурация была идеальна для отлова бага - сильно нагружала сторадж, в остальном в ней не было ничего плохого. Но зачем его ловить, действительно...
> Тут в свежем ядре KCSAN обещают, интересно, что он позволит накопать в этом направлении.
он же вроде по проблеме наступания себе на шнурк...буферы, а не про локи?
> а что notabug - тоже правильно?Хреново это, конечно, но понять можно: увидели они, что проблема где-то рядом, а не ровно там где было указано изначально (а где именно и куда нужно перекинуть — уже не увидели, ибо копать и копать), вот и получалось что формально notabug. А дальше кто замотивирован, тот пусть и копает.
> Кого-то еще удивляет, почему я люблю ntfs, желательно - в оригинале?
Не удивляет, конечно, абсолютно понимаю. Хорошо, когда есть возможность просто сношать мозги MS/Oracle/VMWare/IBM в рамках контракта техподдержки, но такая возможность далеко не всегда есть. И тут ведь такое место, что собираются как раз те у кого возможности нет, а нетривиальные проблемы возникают. И если с закрытым продуктом (да ещё и нередко специально ориентированным на платную техподдержку) в таких случаях вообще хрен что поделаешь, так хоть какие-то шансы появляются.
> То есть конфигурация была идеальна для отлова бага - сильно нагружала сторадж,
> в остальном в ней не было ничего плохого. Но зачем его ловить, действительно...В общем-то, для бесплатной техподдержки вполне неплохой уровень, т.е. если хватит квалификации добивать самому — нужные подсказки они таки дают. Но если самому не хватает, тогда упс, неразгребённых платных тикетов ещё слишком много.
>> Тут в свежем ядре KCSAN обещают, интересно, что он позволит накопать в этом направлении.
> он же вроде по проблеме наступания себе на шнурк...буферы, а не про локи?Да тут такое дело, что когда ВДРУГ производительность ФС (или любой другой подсистемы) падает почти в ноль, но при этом нагрузка на процессор и контроллер очень низкая, а запросы всё равно еле разгребаются, да ещё и начинает проявляться такое состояние только под большой нагрузкой, уж очень это попахивает состоянием гонки где-то. Ну вот очень-очень.
> Про странности конфигурации разработчики правильно отметиливы про размер страйпа? а что странного?
по мне странно для многопоточной нагрузки использовать мелкие чанки, особенно на hdd.вот смотрите, у нас есть 10 дисков, raid 5. производительность массива на определяется в первую очередь сиками (seek), условно по 100 iops на диск.
нам нужно прочитать мегабайт с диска.при чанке в 4мб это будет 1 сик (задействован один диск).
при чанке в 64кб это будет 10 сиков (задействованы все диски).то есть в первом случае мы сможем держать (очень условно) на порядок больше клиентов.
а по причинам проблемы: я подозреваю, что там правильно написано — «теряется» какой-то запрос к блочному устройству (все случаи воспроизведения были связаны с большой дисковой активностью).
ext4 в тех же условиях просто работает (возможно, что-то и портит на диске, но я не замечал)
> вот смотрите, у нас есть 10 дисков, raid 5. производительность массива на
> определяется в первую очередь сиками (seek), условно по 100 iops на диск.
> нам нужно прочитать мегабайт с диска.
> при чанке в 4мб это будет 1 сик (задействован один диск).
> при чанке в 64кб это будет 10 сиков (задействованы все диски).
> то есть в первом случае мы сможем держать (очень условно) на порядок больше клиентов.С чтением-то всё так. А вот для кучи мелких записей (особенно read-modify-write) это проблема.
> а по причинам проблемы: я подозреваю, что там правильно написано — «теряется»
> какой-то запрос к блочному устройству (все случаи воспроизведения были связаны с
> большой дисковой активностью).
> ext4 в тех же условиях просто работает (возможно, что-то и портит на диске, но я не замечал)Как уже говорил выше, ext4 очень старательно кучу мелких записей пытается откладывать на последний момент (дабы в итоге сделать меньшую кучу и более крупных). В итоге этого обходного манёвра, вероятно, у глючного железа при этом так и не наступает такая ситуация, когда запрос дропается. Но и для ext* можно создать такую ситуацию, например, когда делается всё то же удаление/переименование кучи мелких (можно и не мелких) файлов, там уже его трюки не работают и он тоже похожим образом начнёт висеть/еле ползать. И это не единственное, в чём ext4 ведёт себя, гм, нехорошо.
XFS себе таких вольностей не позволяет (сказано писать мелкими кусками, будет писать мелкими кусками и синхронизировать после каждого, а то вдруг сейчас питание прервут или ещё какая война), так что нещадно фрагментируется в таких сценариях (один из самых болезненных его недостатков для меня, пожалуй) и, после какого-то момента тупит. Довольно сильно спасает использование fallocate, кстати говоря (хотя и не всегда, надеюсь, я что-нибудь на этот счёт всё-таки допилю).
У вас когда-нибудь крашилась XFS? У меня за двадцать лет ни одного раза. А вот NTFS -- многажды.
> У вас когда-нибудь крашилась XFS?Почитайте тему. Я даже бэктрейс выложил. Во времена мной ее массового использования - она крэшилась _постоянно_ - никто даже не напрягался - "упала - ребут - поднялась? Хорошо, не поднялась - reinstall".
Единственная fs, которая меня никогда не подводила в линуксе, скорее в силу своей простоты схожей с тупостью - это ext2. Но это ext2 95го года. С кучей проблем как производительности, так и просто работоспособности - после героической победы над которыми в ней слуцилась "massive filesystem corruption", ой, опять.
> А вот NTFS -- многажды.
А у меня за 25 лет - ни разу. Что я делаю не так?
Причем, если на полках порыться, я найду диски с ntfs'ом 2003го года. Один из них немного полуживой в силу чисто механических причин, но fs как-то пока справляется с его проблемами.
ext то ли 2, то ли 3 - не справилась, эти диски у меня образовались после ночной поездочки в ДЦ, где "redundant" коробка с ними внезапно сдохла на ходу.
>Набор вбросов мало относящихся к реальности.исправил
Мда. непонятно зачем коммерческая компания открыла свой драйвер, а эти опять не довльны. Патчи нам разбейте, пожуйте и в рот положите.
Не прошло и хрен знает сколько лет...
> Константин Комаров, основатель и руководитель компании Paragon SoftwareВоооот, сильна Наша Великая и Славная Poccиюшкa талантами! Что бы ни клеветали пендосы треклятые и гейропейцы заднеприводныя! Низкий поклон учёному человеку!
> Воооот, сильна Наша Великая и Славная Poccиюшкa талантами! Что бы ни клеветали
> пендосы треклятые и гейропейцы заднеприводныя! Низкий поклон учёному человеку!только чота-чота фирма у него - Gmbh, а не "ООО".
Да и сцайт, паразит, разместил в амазоне, а не в скрепном облаке-мэйлру!Надо бы товарищмайору как-нибудь зайти к этим умникам на огонек - поинтересоваться, не украли ли они, случайно, интеллектуальную собственность какого-нибудь Рамблера.
stable api is nonsense - с 4.14 несобираемо :-(Ну и забавные фифекты:
> # mount -t ntfs3 /dev/vb1 /mnt
>
> This already triggered UBSAN:
> Then I've tried to copy /etc into it:
> ...
> # cp -rp /etc /mnt
>
> But this triggered a NULL ptr deref:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000028(ответ разработчика - "а мы с туксеровской-то поделкой никогда и не тестировали", с одной стороны - признак дерьмокода, конечно, с другой - признак того что тухлосеровскими тулзами пользоваться - тоже чревато, какую-то шибко оригинальную ntfs создают)
свои mkfs/ntfschk обещают открыть - но тоже когда-нибудь, может быть, в отдаленном будущем.
> stable api is nonsense - с 4.14 несобираемо :-(и, похоже, еще и 64bit-only, и требует самой наираспоследней версии gcc (то есть _новее_ чем требует само ядро)
В общем, как обычно, русские делали - значит точно херня получилась... :-(
не, насчет 64 не угадал, это опять stalbe api nonsense, в какой-то момент все элемены *_time ВНЕЗАПНО стали 64битными на всех платформах. Это к вопросу о "зачем парагону быть в ядре". Вот затем, чтоб не переписывать без конца.Кому интересно побыть пре-альфа-тестером - могу подарить модуль, собранный для ведра 5.4.58 для платформы armhf (читай, le, v7-a, hardfloat) - правда, вам еще понадобится ведро с моим патчем (ничего особенного, в смысле, добавляет сомнительного качества функцию, никем кроме этой ntfs3 не используемую (и той - один раз при открытии тома), поэтому почти безвредную, модулем не соберется.
Сам я, разумеется, даже запускать его не буду.
> в какой-то момент все элемены *_time ВНЕЗАПНО стали 64битными на всех платформахНу почему внезапно, про проблему 2038 все уши прожужжали уже давно. И про то, что она недавно была «наконец-то полностью исправлена» в Linux (на самом деле, конечно, старые приложения и ФС никуда не делись, но на них ядро теперь ругается в dmesg) — тоже.
> Ну почему внезапно, про проблему 2038 все уши прожужжали уже давно.стесняюсь спросить, а проблема 2000го уже окончательно решена, или почти уже совсем но...?
> И про то, что она недавно была «наконец-то полностью исправлена» в Linux
может, если вы настолько специалист в "Linux", вы еще можете мне объяснить, как теперь ЭТО откатить? (ну или хотя бы в комит пальцем ткнуть) "Разумеется, никто не думает что unix просуществует так долго". Я практически вот уверен что _я_ так долго не просуществую, мне не надо этого щастья.
Там на самом деле три проблемы с бэкпортом: корявая реализация ядром readahead - кстати, это то самое, что недавно улучшили в vfat, это можно просто выкинуть из кода (обидно, но бэкпортировать сам readahead я не осилю, там затрагивается слишком много стремных мест в ядре), static_assert из C++ вместо сишного (лечится удалением нахрен) и изменение размерности *_time на 32битных архитектурах.
Я было даже хотел посмотреть, как в коммерческой версии решили эту проблему - посмотрел... на моем ядре (входящем в перечень допустимых) оно в принципе не могло собираться никогда и ни при каких условиях - перепутаны build и source еще на этапе configure.
> стесняюсь спросить, а проблема 2000го уже окончательно решена, или почти уже совсем но...?Очевидно, в старых программах размер того же time_t не изменится (особенно без пересборки), равно как и не пропадут сами собой грязные участки кода типа использования int/unsigned int для отметок времени. И с этим, очевидно, ничего в принципе не сделать. Но, насколько я понимаю, всё что можно было исправить и подпереть костылями в ядре и glibc, таки исправили и подпёрли, теперь всё упирается в legacy-приложения.
>> И про то, что она недавно была «наконец-то полностью исправлена» в Linux
> может, если вы настолько специалист в "Linux", вы еще можете мне объяснить,
> как теперь ЭТО откатить? (ну или хотя бы в комит пальцем
> ткнуть) "Разумеется, никто не думает что unix просуществует так долго". Я
> практически вот уверен что _я_ так долго не просуществую, мне не надо этого щастья.Специалист из меня вот прямо совсем не очень (только и делаю, что чужие косяки выявляю, да иногда исправляю или бумажки пишу), но могу предложить начать поиски с чтения Documentation/core-api/timekeeping.rst и коммитов, которые его меняли. Ещё могу ткнуть не совсем в коммит, но в письмо с серией патчей: https://lkml.org/lkml/2020/1/29/355 , там вот такая ссылка есть: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Т.е. можно посмотреть в git log на коммиты с тегом y2038, вот тут они прям кучно идут: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playgro...
Мда, прочёл не тем местом, 2038 вместо 2000, ну да ладно.
ИМХО, если у кого-то проблема 2000 и не решена, они уже снова тупо расслабились до 2100, проблема-то по большей части на переходе была. А архивные данные уже давно в архивах, кому понадобится прочесть — сами и сконвертируют.
Вау, в яблочко, вот оно:
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playgro...
были функции конверсии одного в другое, и, вероятно, в интересующих меня ядрах - остались.Спасибо, это дает шанс на успешную сборку хотя бы с 4.1x - там всего пяток мест где оно использовалось.
А тем временем наш "Алмаз Александрович" выложили вторую версию (вроде бы - исправленную на тему падений на ntfs'ах, созданных гнутым шлаком, а не настоящей виндой)но, к сожалению, ее оне выложимши как потребовали - "порезанной помельче", поэтому скачать не получится, если только вы не уже подписчик linux-fsdevel
При попытке это сделать, я с удовольствием обнаружил что lore.kernel.org ТЕРЯЕТ почту, и найти три из десяти патчей в нем не получится. Реплаи есть, оригинала нет. Не говоря уже об охеренном удобстве выуживать десять отдельных огрызков из помойки в две тысячи сообщений за день среди ценных комментариев каких-то м-ков, докопавшихся до правописания в комментариях.
А patchworks, похоже, сканирует именно lore - и, естественно, тоже не находит нужных кусков.КАК при таком подходе еще находятся настолько на голову больные люди, чтобы с ЭТИМИ вот сотрудничать и тратить на них свое время?
Хозяйке на заметку: парагоновцы не понимают семантику масок - umask/dmask/fmask у них на самом деле не маски, а сами пермишны (то есть выставляйте dmask=755, а не 022 как у fs написанных теми кто таки пользуется юникс-системами)nls тоже используют как-то "причудливо", то есть драйвер загружает нужную страницу (видно по возрастанию числа линков у модуля) но отдает по прежнему utf8 (this suxx).
time cat /mnt/trash/wrk/china-orig.tar > /dev/null
0.015u 18.478s 0:19.79 93.3% 0+0k 5103328+0io 0pf+0w
~# w
22:56:23 up 24 min, 2 users, load average: 0.28, 0.07, 0.02(39G, не хрен собачий)
Ну хрен знает - для быстро скопировать с "флэшки" на файлохранилку понатыреный филез и варез - наверное, сгодится. В обратную сторону не пробовал, ссыкотно. Да, это у меню кривохакнутое ведро 5.4.58 (впрочем, в данном случае кривохак ничему не мешал, он проявляется когда много мелких файлов, но у меня такого не водится).
0.033u 8.032s 0:21.10 38.1% 0+0k 5103328+0io 0pf+0w
~# w
13:32:58 up 9 min, 2 users, load average: 0.72, 0.18, 0.05это ntfs-3g для сравнения.
Чего-то как-то не особо впечатляющая разница. При этом по набору фич, полезных для лично меня - ntfs3g впереди (существует для всех систем, поддерживающих fuse, не linuxonly, там есть попытки acl mapping и работы с windows-специфичными свойствами fs).
Без journal replay я как-нибудь переживу (то есть я бы предпочел без него, оставив виндово - винде, лучше бы драйвер сразу сообщал что диск некорректно закрыт и не надо его читать тут - но вот такой фичи как раз нет)
> 0.033u 8.032s 0:21.10 38.1% 0+0k 5103328+0io 0pf+0w
> ~# w
> 13:32:58 up 9 min, 2 users, load average: 0.72, 0.18,
> 0.05
> это ntfs-3g для сравнения.
> Чего-то как-то не особо впечатляющая разница.Так надо на куда более скромных железках сравнивать же. Собственно, коммерческую версию сабжа встречал во всякой встроенке, типа TV-приставок. Впрочем, и на не очень старых ПК (типа P3, только не надо мне в дату их выпуска тыкать, очень такой себе аргумент, да, можно сказать что нишебродопроблемы, я не против) ntfs-3g явно упирался в проц (впрочем, я давненько им там не пользовался, возможно, с тех пор и оптимизировали существенно).
> Без journal replay я как-нибудь переживу (то есть я бы предпочел без
> него, оставив виндово - винде, лучше бы драйвер сразу сообщал что
> диск некорректно закрыт и не надо его читать тут - но вот такой фичи как раз нет)Помнится мне, винда (начиная с какой-то версии) и при корректном отмонтировании любит оставлять непустой журнал (типа, а чего: потом всё равно при следующем монтировании винда докатит, а остальные пусть страдают), так что без поддержки log replay нынче драйвер практически бесполезен. А отказ в монтировании при наличии dirty-флага тут и так есть.
> Так надо на куда более скромных железках сравнивать же.это 32битный arm с телефонным процессором
TL;DR : возможно, сравнивать надо было запись мелких файлов. Но мне не надо, а рисковать своими дисками ради теста я не хочу.На более скромной железке я даже не уверен что удастся собрать все нужные детали (напоминаю, хрень неработоспособна без ядра только что из под гузки Торвальдса - запросто окажется что в твоем p3 такое уже и не грузится, из-за бодрого выпиливания поддержки половины немодных устаревших деталей)
> ntfs-3g явно упирался в проц (впрочем, я давненько им там не пользовался, возможно, с тех пор и
> оптимизировали существенно).смеешься? На нее член положон с 2016 - когда надо было наконец собраться с духом и переписывать на fuse3. (постарел Жан-Пьер и тяжело ему пилить в одно жало - венгр с самого начала коммерческой тухеры ни на каком инструменте не играет, он руководитель, как вы, и никто никогда не видел его код, а русский, как обычно, пошел на мороз сразу как запахло деньжыщами)
Вместо этого: https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/275edd5353639ac.../ - особенно 'insert a bootable floppy' умилило.Возможно, если ты НА нее писал на своем пнетри, и это было уже после 2015го года - надо было включить big_writes "очень известный пре-цен-дент, даже в кино...зачеркнуто, википедии отражен!"
(и баг до конца не убран, потому что некому - но какой-то костылик подставлен, обещают диски не разносить в хлам - если ты зачем-то умудришься найти диск <4G на котором он проявляется)> Помнится мне, винда (начиная с какой-то версии) и при корректном отмонтировании любит оставлять
> непустой журналя пока не сталкивался, при том что диски таскаю в основном именно с винды на линукс.
P.S. я,кстати, нашел ту самую табличку, с жалобным "но вообще-то я еще дебаг выключить думаю":
http://web.archive.org/web/20070104130638/http://www.ntfs-3g... после которой бегом, роняя кал, наши "чуваки в авторитете" кинулись улучшать линуксную ext3, а то очень, знаете ли, неудобненько выглядело.
ffuck, как же затрахала автоподстановка левых ников
"Кто с чем к нам, тот от того и того" же :D
лучше б оно Аноним умело подставлять - в комментарии под пустой новостью умеет, а в ответах - "вы забыли заполнить поле name" - да не забыл я, блжад.Зато при показе долбаной капчи - то что я написал, заменяется мусором из прошлого.
Ну, конкретно я ext3 пригодным для использования никогда не считал, это действительно леденящая душу жесть, тут не спорю и ничего удивительного. Да и ext4 до сих пор хранит немало хтонического наследия, но в некоторых случаях приходится всё-таки выбирать его.Насчёт выпиливания поддержки и сборки с несвежим ядром прямо свербит проверить, конечно.
Про big_writes что-то припоминаю, но беды с производительностью точно были и раньше, году так в 2010. Да, небезуспешно писал уже тогда на NTFS, такой вот извращенец.
> Ну, конкретно я ext3 пригодным для использования никогда не считал, это действительноКак будто у тебя выбор тогда был (патчи против massive filesystem corruptions, не сбэкпортированные в ext2, и борьба с лимитом в 2G)
В том и дело что оказалось в тот момент, что в линуксе ни одной нормальной fs. Вой стоял такой, что волки из лесу бежали, тролли нажрались пингвинятины на пять лет вперед.> Про big_writes что-то припоминаю, но беды с производительностью точно были и раньше,
так они потому и были, что big_writes у тебя не было. Они отключены по умолчанию именно из-за умения ntfs3g убивать мелкие флэшки (видимо, находились любители).
Запиши себе в fstab: rw,big_writes - эта пара не должна никогда разделяться, пока не перейдешь на цветную капус...fuse3, где это, наконец - умолчание.
> году так в 2010. Да, небезуспешно писал уже тогда на NTFS,
так в 2010м все работало. С тех пор добавили полуработающий обработчик reparse points и работающий trim (в 2014м ;-) - причем второе сделал совершенно отдельный от проекта человек.
> Как будто у тебя выбор тогда былНу, какой-то выбор был, я всё-таки очень поздно до Linux добрался (где-то между 2004 и 2007). Так что сначала сидел на reiserfs (потому что пользоваться ext2/ext3 было совсем невыносимо), да, иногда загружаясь с внешнего носителя и запуская reiserfsck, иногда даже с ребилдом дерева, а потом открыл для себя XFS (да, опять постепенно открываем и аккуратно обходим заботливо разложенные грабли, но почти всё остальное ещё хуже).
> Запиши себе в fstab: rw,big_writes - эта пара не должна никогда разделяться, пока не перейдешь на цветную капус...fuse3, где это, наконец - умолчание.
У меня NTFS сейчас очень редко встречается, а где встречается — уже было обновление до fuse3. Так что повезло. Но за информацию благодарю, вот прям здорово что наконец-то узнал (всё-таки я далеко не все changelog'и успеваю читать, мягко говоря).
> Ну, какой-то выбор былна одном стуле ассортимент так себе, а на других еще хуже. А так да, был. А через пять лет мы узнали, что гугль все это время жил на ext2. Не возвращая патчи (ок, их мог не радовать метод порежьте-переподайте, но можно было просто выложить).
> У меня NTFS сейчас очень редко встречается, а где встречается — уже было обновление до fuse3.
а она об этом ничего не знает, и использует интерфейс fuse2, так что параметр не лишний.
Говорю же - ниасилил ее единственный разработчик fuse3, он вон - бутсектор заменяет на идеологически верный.
Парагон помню по кривым системным утилитам которые ломили венду. Жаль если их поделку примут я ядро.
хозяйке на заметку: в шестой версии патча маски вылечены, и работают как в остальных fs. Патч https://lore.kernel.org/linux-fsdevel/20200814134056.GV2026&.../ по прежнему нужен.И, главное, чтоб не потерялось:
file.c ntfs_getattr
Надо удалить эти две строчки (и можно само объявление sbi чтоб убрать предупреждение):
stat->blksize = sbi->cluster_size;
stat->blocks <<= sbi->cluster_bits - 9;- они лишние, из-за этого неверно работает du и прочие stat()
Седьмая версия - вроде никаких проблем не добавили, старые вылечены, кривохак для сборки с нераспоследним ядром не нужен (удалить кусок кода с readahead по прежнему нужно, не нужно править ядро вне ntfs3)