|
|
3.4, Аноним (1), 14:24, 26/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
А его не отпустили разве из-за коронавируса? Где-то пробегало вроде.
| |
|
4.51, pda (?), 18:10, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
У него было слушание в марте об условно-досрочном. Насколько я помню не выпустили.
| |
|
|
2.20, Аноним (-), 15:08, 26/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Когда в ядро?
Когда шишкин бэкпортирует. В майнлайн ему врядли светит - не командный игрок.
| |
|
3.153, Аноним (153), 15:59, 27/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> В майнлайн ему врядли светит - не командный игрок.
А команда-то где, с которой надо "играть"? Я пока вижу только сборище толстяков, которые лишь сидят и ждут, когда какой-нить голодный академик с нулевым ЧСВ не придёт, и не починит им всё, пока они улыбаются на кернел саммитах.
| |
|
4.161, Аноним (161), 18:00, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А команда-то где, с которой надо "играть"?
Очевидно, в майнлайне.
> Я пока вижу только сборище толстяков, которые лишь сидят и ждут, когда какой-нить
> голодный академик с нулевым ЧСВ не придёт, и не починит им всё, пока они улыбаются на кернел саммитах.
Ага. А в перерывах между улыбками на саммитах они код пишут. И довольно дофига судя по git log и размеру .git :)
При том академики живут в каком-то своем мире. Виртуальном. Иногда настолько что они даже как видим не в курсе чего уже придумали коллеги по цеху и с помпой преподносят изобретенное колесо. А тут оказывается что какой-то скунс уже это изобрел год назад. Ну не заговор ли это против академиков?!
| |
|
|
|
1.2, Аноним (2), 14:10, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Лучше cкажите, код переписали для соответствия требованиям к стилю в ядре Linux и избавились от дублирующих примитивов? Или как раньше нет шансов на включение в винильное ядро?
| |
|
2.6, sfdsf (?), 14:27, 26/05/2020 [^] [^^] [^^^] [ответить]
| +12 +/– |
Вылезайте из криокамеры, эти все детские придирки были устранены еще при Райзере (до того как он в тюрьму сел). Код не принимали в свое время из-за личной неприязни (привет Коливасу).
| |
|
3.7, Аноним (7), 14:30, 26/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Коливас -- отвратительный сверхтоксичный человек, и код его глючный и безграмотный. Так что не удивительно. Но вот ведь, запихнули в ядро.
| |
|
|
5.15, Аноним (7), 14:52, 26/05/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
> А кто там факами размахивает не токсичный что ли?
Факами размахивает истеричка, истеричка -- не обязательно токсичный. Да и впрочем достижения там не в пример больше.
| |
|
4.21, Аноним (21), 15:12, 26/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Коливас -- отвратительный сверхтоксичный человек
Умные люди все со своими тараканами в голове. Иногда эти тараканы устраивают крестовые походы друг на друга, по поводу и без.
Насчет сверх - да не факт. Между делом, Коливас таки снискал себе приличную известность, накодив один из самых крутых майнеров биткоина, используемый легионом народа, а также пул и еще много всякого вокруг. Так что в целом он в софтостроении отличная от нуля величина. Но с ядерщиками у него как-то не задалось.
| |
|
5.25, Аноним (1), 15:19, 26/05/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
А ты пробовал туда патч отправить? Тот ещё квест и без всяких гарантий. Если ЧСВ отлично от нуля, то рано или поздно устанешь от этого процесса. Можешь конечно там жить в рассылке и стать "своим", но проще у себя пропатчить и забыть.
| |
|
6.30, Аноним (30), 15:38, 26/05/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
А что сложного? Я отправлял, чуть ли не через пару часов Мортон взял в ветку next, ну а через пару недель перезаложит в ветку Линус. Никаких сложностей не заметил.
| |
|
7.39, Аноним (39), 16:17, 26/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> А что сложного? Я отправлял, чуть ли не через пару часов Мортон взял в ветку next
Кодинг стайл поправлял, или ошибки в комментсах фиксил?
| |
|
8.81, fghj (?), 21:58, 26/05/2020 [^] [^^] [^^^] [ответить] | +4 +/– | Последний раз поправил работу с FIFO контролерра клавиатуры, которая приводила к... текст свёрнут, показать | |
8.99, Аноним (99), 08:44, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Я вот например константы подрихтовал Вопрос в том где они были и что за констан... текст свёрнут, показать | |
|
|
6.98, Аноним (99), 08:40, 27/05/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Да Правда немного смухлевав через знакомого майнтайнера А кто и какие гарант... большой текст свёрнут, показать | |
|
5.62, Anonymous Coward (?), 19:40, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
А в действительности... всё не так как на самом деле!! (c)
Всё в порядке у Коливаса с ядерщиками (с теми самыми что планировщик в mainline пилят), на одном IRC канале сидят, за жизнь толкуют. И отношения дружеские. Инфа из первых рук. :)
| |
|
|
3.89, Аноним (89), 02:56, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Код не принимали в свое время
из-за того, что Ганс отказался продолжать поддерживать reiser3 и вместо этого переключился на разработку следующей версии без обратной совместимости. Линус сказал, что поддерживать зоопарк чужих файловых систем вместо их разработчиков ему в рог не впёрлось и что больше от этого разработчика в основной код ядра он ничего принимать не будет.
| |
|
4.100, Аноним (99), 08:48, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> зоопарк чужих файловых систем вместо их разработчиков ему в рог не
> впёрлось и что больше от этого разработчика в основной код ядра
> он ничего принимать не будет.
Ну так эта ситуация ставит Торвальдса в позу. С одной стороны он обещал что юзермод не ломают. С другой, reiser3 никто не майнтайнит и его стало быть надо выкинуть, прокатив пользователей с этим обещанием. Потому что иначе это станет якорем для остальных подсистем.
...а когда тебе предлагают навалить вторую порцию такого "счастья" это почему-то может и не выглядеть таким уж заманчивым предложением с точки зрения общей координации проекта.
| |
|
|
2.8, Sluggard (ok), 14:35, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ты путаешь ReiserFS и Reiser4. Первая давно в ядре, но и у второй ещё 10 лет назад всё причесали вроде, поищи интервью с Шишкиным.
| |
|
3.13, Аноним (1), 14:49, 26/05/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
>Первая давно в ядре
Только повыкидвали из основных дистров. Так просто не поставить.
| |
|
4.22, Аноним (21), 15:14, 26/05/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Что значит повыкидыввали? Модули ядра есть, пакеты с утилсами есть. А то что просто не поставить - ну, знаете, может быть дистроклепателям не очень хочется объясняться перед юзерами почему fsck том разнес в хламину так что оттуда вообще теперь ничего вытащить невозможно, "но вы можете доплатить Namesys за услуги по дата рекавери"?
Вообще, идея сделать фс а потом барыжить дата рекавери с нее достаточно интересна :)
| |
|
5.27, Аноним (1), 15:24, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Тебя прям послушаешь, кроме ext4 вообще ничего лучше не оставлять. Все файловые системы могут накрыться медным тазом даже без fsck. Впрочем, стоны были слышны исключительно в сторону reiserfs3, результат чего мы сейчас и наблюдаем. И пофиг, что в ядре оно торчит и вполне сносно работает.
| |
|
6.29, Аноним (29), 15:28, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Тебя прям послушаешь, кроме ext4 вообще ничего лучше не оставлять.
Плохо слушаешь - это любитель смуз^W БТРФС (которая у него 5 лет уже вот-вот совсем почти скоро готова и захватит мир - фейсбук и миллионы его подопытных хомячков не дадут соврать и прочее в том же духе).
| |
|
7.102, Аноним (102), 08:59, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Плохо слушаешь - это любитель смуз^W БТРФС (которая у него 5 лет
По-моему больше. И кроме миллионов фэйсбучных хомячков я и сам его потестил в разных ситуациях, вон даже на системе с битой RAM погонял, пох спросил чего будет, мне стало интересно. Получилось в общем то много чего. Кроме собственно убиения данных, они остались более-менее корректны даже в настолько идиотском случае.
Основным достижением стали матюки на CSUM ERROR, corrected в лог. И кстати RAID в чистом виде с такой ситуацией справляться не обязан. Даже если мы видим что данные не совпадают, в обычном RAID мы понятия не имеем какая копия верна. А вот с чексумами это уже интереснее.
| |
|
6.85, Аноним (85), 00:29, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
На моей памяти reiser3 - единственное, что фатально накрывалось медным тазом без фатальных хардварных сбоев. Это, правда, было 14 лет назад, но тот день надолго запомнился.
| |
6.101, Аноним (102), 08:56, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Я себе btrfs в основном оставил В нем кстати fsck нечто не используемое в н... большой текст свёрнут, показать | |
|
5.31, Аноним (39), 15:46, 26/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> "но вы можете доплатить Namesys за услуги по дата рекавери"
Они деньги брали за вытаскивание данных с неработающенго железа (напр. с бэдами).
Или для тебя это тоже нужно бесплатно делать?
| |
|
6.104, Аноним (102), 09:05, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Они деньги брали за вытаскивание данных с неработающенго железа (напр. с бэдами).
Пардон, но довольно типовой (анти)паттерн reiser3:
1) Крах.
2) Unable to mount... на уровне ос
3) fsck
4) Полная вермишель из тома как результат этого деяния.
5) "FUCK YOU REISER!!!" (testimonials)
> Или для тебя это тоже нужно бесплатно делать?
Я даже соглашусь насчет бэдов, но вышеупомянутый антипаттерн случался и на вполне исправном железе. И с таким антипаттерном не так уж важно насколько быстра ФС и какие у нее есть клевые фичи, если есть измеримый шанс получить вот это, вот так.
| |
|
7.240, Аноним (-), 10:42, 30/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
p.s. кстати возможность получить большинство данных малой кровью даже если были бэды - для ФС явно в плюс :).
У ext4 fsck тома не убивает и обычно вытягивает даже довольно побитые сторажи до чего-то моунтабельного и большинство данных все же достать можно.
В btrfs если все совсем плохо - есть offline reader прямо в тулките, им можно вычитать файло на другой носитель вообще неразрушающе и без монтирования, накрайнях опробовав еще и разные точки входа.
...а чего делать в reiserfs если он перестал маунтиться, а fsck оказался бесполезен, а то и вовсе все урыл? Ну, кроме как идти платить namesys, конечно. Что довольно странная идея - платить фирме за их баги.
| |
|
|
9.248, Аноним (248), 21:01, 30/05/2020 [^] [^^] [^^^] [ответить] | +/– | Ну вот лично я c ext4 допустим могу вынуть данные и без всего этго Даже с основ... большой текст свёрнут, показать | |
|
|
|
|
|
4.34, Аноним (35), 16:00, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
В Вашем воображении, разве что
cat /proc/filesystems | grep reiser
reiserfs
cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
| |
|
|
6.83, Аноним (35), 22:31, 26/05/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Тормоз, в последней ubuntu reiserfs не удалили, а ты ссылку 2013 года кидаешь. Мозги совсем в студень превратились?
| |
|
|
|
|
|
1.5, Аноним (5), 14:24, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Я правильно понимаю, что разработчики reiser реализовали то, что уже умеет bcache и dm-cache?
| |
|
2.10, Аноним (153), 14:38, 26/05/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
То, что они реализовали, bcache и dm-cache в принципе уметь не может.
| |
|
|
4.66, zfs (??), 19:54, 26/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
да, мы-то не смогли додуматься ВРУЧНУЮ zil по крону сбрасывать.
| |
|
5.116, Аноним (-), 09:43, 27/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> да, мы-то не смогли додуматься ВРУЧНУЮ zil по крону сбрасывать.
Ну так в этом половина смысла - девайс всегда расчищен и всегда готов к новому burst. А менеджить подобные вещи из cron... спасибо, но нет. Сопли и скотч в файловой системе все же не заканчиваются чем-то хорошим.
| |
5.130, Аноним (129), 12:39, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну так нужно понимать, что Шишкин в одно лицо пилит. У него не 100500 рук. Reiser5 даже не betta ещё.
| |
|
|
|
2.18, Аноним (153), 15:01, 26/05/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
> уже умеет bcache и dm-cache
А как тебе bcache dm-cache узнают, что это пики IO-load, которые надо на прокси-диск отправить? Такое только файловая система знает.
| |
|
3.75, пох. (?), 20:21, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> А как тебе bcache dm-cache узнают, что это пики IO-load, которые надо на прокси-диск отправить?
а как fs о них узнает? Никак, в смысле - постфактум только.
| |
|
4.87, Аноним (153), 02:34, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
а как fs о них узнает?
Непосредственно. Кто, как не ФС знает, что это новый логический блок? А в block layer передаются безликие запросы ввода-вывода. bcache и dm-cache ничего не знают от слова совсем.
| |
|
|
|
1.9, Аноним (9), 14:35, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Эдуард Шишкин анонсировал
Ну а толку то, оно же не в ядре. А Шишкину западло заниматся багами.
| |
|
2.11, Аноним (153), 14:40, 26/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ну а толку то, оно же не в ядре
Ну и что? ZFS тоже не в ядре.
| |
|
|
4.32, Заноним (?), 15:52, 26/05/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Ну так он и является в лине куском головняка. За что и
> умрет.
Детсад какой-то. ZFS в linux работает без всякого "головняка". Да zfs скорее всего умрёт в linux, но не раньше, чем btrfs окончательно достигнет аналогичной функциональности и надёжности.
| |
|
5.60, Аноним (7), 19:18, 26/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>zfz
>inux
>надёжность
Тем временем btrfs уже 10 лет стоит на всех хомячковых насах и дисковых полках от synology.
| |
|
6.68, пох. (?), 19:58, 26/05/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
это тех самых, которые сейчас у всех немножечко майнят?
Ну да, стоит (в хомячковых, с полками - это пока больше фантазии). Вы думаете, это от того что synology так уж заботит судьба ваших даных?
| |
|
7.117, Аноним (-), 09:47, 27/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> это тех самых, которые сейчас у всех немножечко майнят?
Как насчет пруфца этого громкого заявления? И эт, майнеру пофиг на файловую систему, так кто как это к btrfs относится? :P
> Ну да, стоит (в хомячковых, с полками - это пока больше фантазии).
> Вы думаете, это от того что synology так уж заботит судьба ваших даных?
Пох, ну тебе ли не знать что "as is" пишут все? Можно подумать, кто-то прямо берет под козырек и идет возмещать хомячкам (или НеХомячкам) ущерб, сколь-нибудь отражающий фактическую ценность данных.
| |
|
8.201, пох. (?), 22:18, 28/05/2020 [^] [^^] [^^^] [ответить] | +/– | https lmgtfy com q synology vulnerability s b что там последнее в смысле, к... большой текст свёрнут, показать | |
|
9.212, Аноним (212), 09:18, 29/05/2020 [^] [^^] [^^^] [ответить] | +/– | Пох открыл для себя базу CVE Ты прав, Пох безопаснее всего выключенный комп... большой текст свёрнут, показать | |
|
|
7.132, Аноним (129), 12:45, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
>это тех самых, которые сейчас у всех немножечко майнят?
Сравнение про ФС и про майнинг, это, как про тёплое и мокрое.
| |
|
6.125, Аноним (125), 10:59, 27/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
А в чем выражается ненадежность ZFS на Linux? На моем домашнем насе переехал с фряхи на дебиан ради привычного окружения, за год не видел пока никаких проблем. Что ожидает?
| |
|
7.127, Аноним (7), 11:31, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Я знаю только о ненадёжности на эксбсд на домашних подкраватных полках она расс... большой текст свёрнут, показать | |
|
|
5.106, Аноним (-), 09:14, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Детсад какой-то. ZFS в linux работает без всякого "головняка".
Не считая того что тут мистер пох таки спалил контору, когда оно при апдейте ядра таки отпало походу. Особенно круто если так с системным сторажем, гули. А, ну да, зачем нам снапшоты системы и прочие глупости? :)
> аналогичной функциональности
У него на уровне дизайна есть и кое-что за пределами этой функциональности. Типа нормального отношения к смеси уровней райдов и возможности это все на лету переигрывать.
> и надёжности.
Я подсовывал оному довольно дурацкие ситуации. И имею заметить что он выживает на карте памяти где EXT4 за пару недель становится полной тыквой, например.
| |
|
6.202, пох. (?), 22:26, 28/05/2020 [^] [^^] [^^^] [ответить] | +/– | ну так передавайте привет альтернативно-одаренным разработчикам бубунточки - на ... большой текст свёрнут, показать | |
|
7.213, Аноним (213), 09:31, 29/05/2020 [^] [^^] [^^^] [ответить] | +/– | Блин, пох, я тебе сразу сказал что все это будет работать так И убунта тут не п... большой текст свёрнут, показать | |
|
|
|
|
|
|
1.26, Аноним (26), 15:22, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> В основу реализованного метода легло простое наблюдение, что на практике запись на диск не ведётся постоянно, а кривая нагрузки ввода-вывода имеет форму пиков. В промежутке между такими "пиками" всегда имеется возможность сбросить данные с прокси-диска, переписав в фоновом режиме все данные (или же только часть) в основное, "медленное" хранилище. Таким образом, прокси-диск всегда готов к приёму новой порции данных.
Шишкин переизобрел SSHD?
| |
|
2.37, Аноним (35), 16:13, 26/05/2020 [^] [^^] [^^^] [ответить]
| –5 +/– |
Такими темпами в линуксе все те возможности которые давно есть в ntfs появятся лет через 20
| |
|
|
4.73, пох. (?), 20:19, 26/05/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
не линуксоиды, а один отщепенец, не идущий строем в ногу.
В линухе readyboost как не было, так и нет. Это слишком сырая технология, лет через десять можно будет скопировать - как раз станет никому не нужна.
А мы пока вручную будем prefetch заполнять при загрузке, надежно, на века.
| |
|
|
|
1.33, Аноним (33), 15:54, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Т.е. по сути просто реализована поддержка кэширования записи на быстрый диск?
| |
|
2.36, Аноним (39), 16:11, 26/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Т.е. по сути просто реализована поддержка кэширования записи на быстрый диск?
Нет там никакого кэширования. Там миграция. Кэширование - это "и там и тут". Миграция - это "или там, или тут".
| |
|
1.40, Аноним (40), 16:42, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Выглядит здорово, спасибо разработчику. Я видел в продаже диски с высокоскоростной малой частью и обычной прочей - похоже Рейзер очень хорошо подойдёт для таких дисков.
Также, буду благодарен за сравнение Рейзер5 с ехт4, бтрфс и зфс.
| |
|
2.70, пох. (?), 20:05, 26/05/2020 [^] [^^] [^^^] [ответить] | –3 +/– | на самом деле ровно наоборот - с дико тормозной основной частью ибо smr и slc ... большой текст свёрнут, показать | |
|
3.181, Андрей (??), 04:23, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Про остальных трех мы хотя бы знаем, примерно, когда и каким образом они превращаются в тыквы, и чего точно делать не надо.
Ну, с btrfs понятно. А какой блэклист для операций у ZFS? Но особенно инетересно об ext4.
| |
|
4.203, пох. (?), 22:50, 28/05/2020 [^] [^^] [^^^] [ответить] | +/– | я вот там выше ссылку кинул - это тебе вот точно понятно Хотя на фоне внезап... большой текст свёрнут, показать | |
|
5.215, Аноним (215), 09:42, 29/05/2020 [^] [^^] [^^^] [ответить] | +/– | Хорошая у поха криокамера, с ядром 2 6 18, там поди и солярис еще живой и веселы... большой текст свёрнут, показать | |
|
|
|
2.90, Аноним (153), 03:02, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Также, буду благодарен за сравнение Рейзер5 с ехт4, бтрфс и зфс.
Тут особо нечего сравнивать. Создай прокси-девайс из рамдиска и добавь его. Скорее всего, все
данные будут падать на этот рамдиск, как и было обещано. Остальные ФС так не могут. Вот теперь и
прикинь, кто быстрее.
| |
|
3.107, Аноним (-), 09:16, 27/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Тут особо нечего сравнивать. Создай прокси-девайс из рамдиска и добавь его.
Какой сложный и извратный способ изобрести кэширование файловой системы. Правда это умел еще smartdrv в MSDOS, блин, но велосипед, конечно, зачотный.
| |
|
|
5.142, Аноним (-), 14:35, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А smartdrv в MSDOS это не про сжатый диск?
Нет, это кэш отложенной записи, многократно разгонявший скорость записи на винч. Про сжатие DoubleSpace и DriveSpace (dblspace и drvspace) были. В линухе вроде даже была поддержка, которую если не ошибаюсь, не так давно выкинули как раз - т.к. походу юзеров этого на глобусе тупо не осталось.
| |
|
4.138, Аноним (153), 13:42, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Какой сложный и извратный способ изобрести кэширование файловой системы.
А чего сложного в "volume.reiser4 -x DEV MNT"?
Если у тебя ФС на медленных дисках, то какое-то телодвижение сделать по-любому придётся, чтобы пристегнуть быстрый диск. Сам он не пристегнётся по мановению волшебной палочки.
| |
|
5.143, Аноним (-), 14:37, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> А чего сложного в "volume.reiser4 -x DEV MNT"?
Я просто к тому что вообще, в нормальной ситуации, RAM и так будет поюзана дисковым буфером ;). А оформить это нечто как RAM-диск - это чтобы его никак нельзя отобрать было, типа на манер ZFS?
> Если у тебя ФС на медленных дисках, то какое-то телодвижение сделать по-любому
> придётся, чтобы пристегнуть быстрый диск.
Реверанс был сугубо про RAM диск и пойнт этого начинания. Если это какой-то иной диск, то это совсем другой вопрос.
| |
|
6.154, Аноним (153), 16:06, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Реверанс был сугубо про RAM диск и пойнт этого начинания. Если это какой-то иной диск, то это совсем другой вопрос.
Изначальный вопрос был про тестирование. Для этого достаточно обойтись лишь рамдиском. Для
серьёзных целей, разумеется, придётся прикупить память на батарейках.
| |
|
|
|
3.122, anonymous (??), 10:08, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Для других ФС использовать bcache?) А вообще и без кэша было бы интересно посмотреть.
| |
|
4.173, ОЛЕГ (?), 21:29, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Bcache крайне несоветую!
как-то ради прикола Снял кешовый ssd проверил- живого места нет, а вся система говорила что все ок
Т.е что там итого записалось хз
Под базой реплики юзал, благо не бой...
| |
|
|
|
1.41, kusb (?), 16:53, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
А можно вопрос, ну или несколько? Почему файловые системы такие сложные и почему они могут так интересно и своеобразно терять данные? По моему даже те, на которые запись не велась уже давно.
Я воображаю себе файловую систему, как "tar "архиватор"", ну или как "cat "file1 >> file2" плюс заголовок вместе с блоками."
Но читая новости складывается впечатление, что создать современную файловую систему это прямо-таки ужас как сложно.
И ещё вопрос: Зачем этот уровень внутри файловой системы, а не блочного устройства? Тот же Интернет разнесён похожим образом на уровни, а тут они вместе. Так бы все фс можно было использовать таким способом. Будет хуже? Где?
| |
|
2.42, Thony (?), 17:19, 26/05/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Проблема не в том, чтобы создать [какую-то] файловую систему, проблема в том, чтобы создать _эффективную_ файловую систему. Нагрузки на диски бывают самые разнообразные, с самими разнообразными шаблонами, требования к фичам тоже. В итоге, каждая ФС выбирает свои приоритеты.
| |
2.44, Аноним (7), 17:29, 26/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Потому что с ext4 слишком скучно жить. Людям подавай ков, волюмы, отсутствие ограничений, присущих "простым" вариантам хранения, сжатие, и всё остальное вроде упаковки хвостов. А сабж хранит данные по принципу дерева, а это несколько отличающийся вариант хранения информации. У него есть свои недостатки. Насколько я знаю, у всех подобных систем есть проблемы с балансировкой, распуханием, и саморазрушением.
| |
|
3.108, Аноним (-), 09:19, 27/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> я знаю, у всех подобных систем есть проблемы с балансировкой, распуханием,
> и саморазрушением.
А у ext4 есть просто пофигизм в отношении к данным. Ему плевать что с ними случится. Если винч отгрузит какую-то труху или RAM дурит, или что еще - вы это узнаете только когда файлы почему-то превратятся в тыкву, если не вся ФС. А то вон у юзерей с ntfs все выглядело ЗБС. До момента когда он перестал монтироваться и scandisk не смог его починить, так что те ощутили себя почти клиентами namesys'а. Ну правда бабки за приседания срубил я а не namesys. А как вам идея если бы MS за бабки предложил сделать это самое? :)
| |
|
4.124, Аноним (7), 10:52, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> А у ext4 есть просто пофигизм в отношении к данным. Ему плевать
> что с ними случится. Если винч отгрузит какую-то труху или RAM
> дурит, или что еще - вы это узнаете только когда файлы
> почему-то превратятся в тыкву, если не вся ФС.
Это в любой фс так (ну во всяком случае в btrfs не лучше, хотя там всё подписано, а не только метаданные).
| |
|
5.144, Аноним (-), 14:45, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Это сильно не соответствует действительности Я проверял Ext4 вообще для начала... большой текст свёрнут, показать | |
|
6.150, Аноним (7), 15:27, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | А если неоткуда, btrfs рассыпается и теряет все данные, даже если там один бит ф... большой текст свёрнут, показать | |
|
7.155, Аноним (-), 16:15, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | то чего вы ожидали Однако даже на единичном механическом диске оно кладет me... большой текст свёрнут, показать | |
|
|
9.165, Аноним (-), 18:24, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Как по мне - это вполне хорошая и правильная цель, экономящая немало нервных кле... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
3.109, Аноним (-), 09:24, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Весьма кривая дока сомнительной компетентности:
1) Толком не учитывает существование btrfs
2) Не объясняет что btrfs-у мешает раскидывать запросы на эн девайсов
3) Не в курсе что btrfs таки aware of какие там девайсы и где.
Итого: господин Эдуард поломался посмотреть вокруг на то что уже есть и что оно делает - но объявил что там есть фатальный недостаток. Офигенно.
| |
|
4.110, Аноним (-), 09:26, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
4) Да, очень хотелось бы понимать что гражданин Шишкин обозвал в btrfs "своим блочным уровнем". Вроде бы там нет ничего похожего на это. Как максимум там есть своя адресация, но это нечто иное и оно может учитывать девайсы в процессе.
| |
4.131, Аноним (153), 12:45, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Для того, чтобы понять эту доку, надо как минимум владеть английским языком.
У btrfs O(1)-аллокатор есть? Фибер-страйпинг есть? Параллельное масштабирование она может? Поддержка прокси-диска есть? Ничего этого там нет!
| |
|
5.146, Аноним (99), 15:01, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | А я и владею И претензии были к конкретно вон тем заявлениям про блочный урове... большой текст свёрнут, показать | |
|
6.156, Аноним (153), 16:26, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Вот прокси-диска - да, нету
Вот когда будет - приходи, поговорим!
Это топик посвящён _существующим_ фичам reiser5, т.е. тем, которые можно потрогать руками, протестировать.
| |
|
7.166, Аноним (-), 18:30, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Народ сослался на вику, я нашел в ней явную кривизну и несоответствия. Nothing more, nothing less.
| |
|
6.176, Аноним (153), 23:10, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> O(1) довольно абстрактно
O(1) - это довольно конкретно. Процесс берёт одну нужную маленькую карту свободных блоков, а не шароёбится по единственной здоровой в поисках свободного места (особенно, если его там осталось мало)
> и не является достоинством без подтверждения бенчами.
если ты их не видел, то это не значит, что их нет
> По 10 секунд на каждую операцию при любых условиях - это тоже O(1), но радости с него будет мало
Словесный понос.
Тебя никто не заставляет гробить 10 секунд на каждую операцию.
| |
|
7.186, Аноним (-), 09:01, 28/05/2020 [^] [^^] [^^^] [ответить] | +/– | Это абстрактное заявление, ничего не говорящее сколько операций в единицу времен... большой текст свёрнут, показать | |
|
|
|
4.137, Аноним (153), 13:34, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Не объясняет что btrfs-у мешает раскидывать запросы на эн девайсов
btrfs - это тот же RAID, который уже имеется на block layer. Т.е. запросы там раскидываются на уровне трансляций дисковых адресов. В Reiser5 всё совсем по-другому. Запросу сначала назначается диск, на который он будет записан (назначает пользователь, либо автоматически - алгоритмом фибер-страйпинга). А уже только после это ФС выделяет адрес на том диске.
| |
|
5.147, Аноним (99), 15:10, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Абсолютно не тот же Btrfs на свободном месте девайса аллоцирует block group ... большой текст свёрнут, показать | |
|
6.148, Аноним (148), 15:13, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
p.s. в btrfs устройствам не обязательно быть одного размера - при втыкании девайса это просто место куда можно класть block groups по указанным правилам. Очень удобно менеджить в отличие от блочного RAID - добавить девайс с +X места или даже изъять с -X места вполне себе ненапряжно и относительно быстро. Если на девайсе данных не было так и его ремув почти моментальный. Удачи так с блочным RAID который надо по всей площади перестраивать.
| |
|
|
4.157, Аноним (153), 16:29, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Толком не учитывает существование btrfs
Есть встречное мнение, что btrfs-разрабы не учли существование reiser4.
| |
|
5.167, Аноним (167), 18:39, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Есть встречное мнение, что btrfs-разрабы не учли существование reiser4.
Возможно. А там есть какие-то уникальные фичи, принципиально недостижимые в btrfs? Например, какие? Шишкин в своей критике обычно упирал на теоретические синтетические кейсы, что ничего не говорит о перфомансе или user visible фичах. Впрочем btrfs мы лю не за это, а за удобный, логичный и дружелюбный менеджмент, за early warnings о надвигающихся факапах, за то что можно быть более или менее уверенным что если прочлось - то это то что записали, а не что-то иное. Что достаточно актуально если данные начинают исчисляться в терабайтах.
| |
|
4.160, Аноним (153), 17:33, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Шишкин сказал, что для реализации своих идей относительно логических томов он ра... большой текст свёрнут, показать | |
|
5.168, Аноним (-), 18:57, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Каждый первый програмер именно так говорит Однако зубоскальство про NIH имеет о... большой текст свёрнут, показать | |
|
6.169, Аноним (153), 19:41, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> И вроде более-менее получилось
Ну вот, у тебя есть шанс доказать это, реализовав прокси-диск в btrfs ))
| |
6.170, Аноним (39), 20:42, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> я однажды имея сугубо юзерские права положил общесистемный перфоманс EXT4 до состояния плинтуса. И даже снос всех моих данных с хоста уже ничего не поменял. Тоже в общем то DoS по большому счету.
Это не иначе, как заговор академиков против честных разработчиков ядра Линукс!
| |
|
7.189, Аноним (-), 09:17, 28/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Это не иначе, как заговор академиков против честных разработчиков ядра Линукс!
На самом деле этот фокус можно повторить с любой ФС. Если кто думает что разработчики имеют хоть какой-то шанс предусмотреть все выходки юзерей в всех мыслимых конфигурациях - напрасно. Так что козырять такими же вещами - хороший способ ощутить себя в шкуре мозилы корп козырявшей безопасностью браузера. Ну им over 9000 vuln'ов и нашли.
| |
|
6.171, Аноним (39), 20:49, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Вообще-то история немного не такая. Ее изначально взяли, в экспериментальном режиме. Но тем временем из RH как-то подразбежались в другие фирмы разработчики ФС и блочного уровня
Ясное дело, подразбежались! Их там заставляли из btrfs энтерпрайз делать, а в шапке стандарты очень
высокие! Это тебе не Суся какая-нить с анбрейкабл Орацлом.
| |
|
7.188, Аноним (-), 09:15, 28/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> шапке стандарты очень высокие!
Особенно заметно на редхатовском пакетном менеджере - хуже я просто не знаю. Сейчас даже уже фрибсд что-то более вменяемое сделали. Факин лол!
| |
|
8.255, _ (??), 19:43, 05/06/2020 [^] [^^] [^^^] [ответить] | +/– | Вообще то ВНЕЗАПНО - во фряхе лучший пакетный мэнэджер, из всего что есть на сег... текст свёрнут, показать | |
|
|
6.172, Аноним (39), 20:56, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> А я то думал что для эффективного распараллеливания надо стараться пулять блоки сразу в эн устройств
С тобой всё ясно, иди изучай матчасть!
| |
|
7.190, Аноним (-), 09:23, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> С тобой всё ясно, иди изучай матчасть!
Так там на вики вот прямо так и написано. В начале. Потом там еще совершенно ушибленное формльное определение идет, однако оно сформулировано так что само себе противоречит. Автырю оного нехило бы прочитать что он написал, взять словарик английского языка и проверить значение слов. А то там прямо какой-то #define true false //have a nice debug session! (автырь переколпачивает или странно юзает значения половины слов).
| |
|
|
|
|
|
12.233, Аноним (39), 00:49, 30/05/2020 [^] [^^] [^^^] [ответить] | +/– | В той статье из вики есть предыстория Previous Art , из которой становится поня... большой текст свёрнут, показать | |
|
|
|
|
|
|
6.175, Аноним (153), 22:50, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Ее изначально взяли, в экспериментальном режиме. Но тем временем из RH как-то подразбежались в другие фирмы разработчики ФС и блочного уровня, как я понимаю в RH тупо нет ни 1 кадра который бы в этом разбирался
Ну, детский сад какой-то чесслово!
"Разработчики не разбежались" не есть критерий того, что экпериментальная фича успешно прошла "technical preview" в Red Hat. Название "technical preview" само за себя говорит. А что будет, если разработчики разбегутся после того, как её возьмут в продакшн? Не задавались таким вопросом? А жаль!
| |
|
7.187, Аноним (-), 09:10, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> "Разработчики не разбежались" не есть критерий того, что экпериментальная фича успешно
> прошла "technical preview" в Red Hat. Название "technical preview" само за
> себя говорит. А что будет, если разработчики разбегутся после того, как
> её возьмут в продакшн? Не задавались таким вопросом? А жаль!
Зато у редхата проходит preview тормозной глючный пихонокрап, вплоть до пакетного менеджера дохнущего жестокой смертью с харакири базе пакетов. После чего система становится малость тыквой. Но это ничего, картонный макет пакетного менеджера в системе их не напрягает. Пардон, релизиться >10 лет к ряду с калом вместо пакетного менеджера - не больно какой стандарт качества.
| |
|
|
|
|
|
|
1.43, Thony (?), 17:23, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Идея с прокси-диском в составе тома прикольная, но, к примеру, что если некоторые файлы мне хочется постоянно иметь в быстром доступе? Поди придумает атрибуты для каталога?
| |
|
2.49, Аноним (153), 17:55, 26/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> что если некоторые файлы мне хочется постоянно иметь в быстром доступе?
Я так понимаю, что с этим проблем не возникнет. Присвой им максимально высокое значение
"температуры", и сканнер не будет их трогать. Шишкин говорил, что нет пока алгоритмов для
определения критической температуры, всё что ниже которой выгоняется с прокси.
| |
|
|
2.149, Аноним (148), 15:15, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Есть у неё какие-нибудь плюшки для SSD?
Ну вот плюшка юзать SSD для затыкания амбразуры^W^W обеспечения быстрой записи по всей площади большого диска.
| |
|
|
2.71, пох. (?), 20:13, 26/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
и само количество половинчатых решений ничуть ведь не намекает вам, что все три варианта - в лучшем случае УГ, а в более реалистичной трактовке - еще и опасное для данных УГ.
Вот кокретно про zfs есть совершено четкая информация от разработчиков, неоднократно ими озвучивавшаяся - что l2 нужно использовать только в одном-единственном случае - кончились слоты оперативной памяти, а working set хотя и больше, но конечен. zil нужно использовать примерно никогда, все попытки его использования, обычно - от непонимания, как он работает, и только ухудшают дело.
Тут хотя бы попытка подойти к делу с другой стороны. Не факт что удачная, но по крайней мере это интересный эксперимент.
| |
|
3.112, Аноним (-), 09:28, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Во всяком случае, общая идея не выглядит чем-то идиотским. Но вот в упомянутой вике гражданин Шишкин конкретно протупил походу. Ему видимо не говорили что из своей кельи иногда стоит высовывать нос и смотреть вокруг. И тогда окажется что половину колес уже изобрели, или что они работают не так как тот себе возомнил :)
| |
|
|
1.57, Аноним (57), 18:59, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
>Data Tiering
[trollmode] Теперь тиринг еще и в ФС! Бесплатно и без смс! [/trollmode]
| |
|
2.118, Аноним (-), 09:51, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> [trollmode] Теперь тиринг еще и в ФС! Бесплатно и без смс! [/trollmode]
Английский язык иногда бывает забавным. Не стоит путать friend и fiend... :)
| |
|
|
2.74, Михрютка (ok), 20:19, 26/05/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
он боится, что shishkinfs русские будут писать на опеннете сиськинфс, а американцы на каком-нибудь реддите - shitkinfs
| |
2.88, Аноним (88), 02:40, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что она все ещё во многом основана на идеях и реализации ее изначального автора.
А алгоритмы и код не становятся хуже (или лучше) от не относящихся к программированию поступков их автора.
| |
|
1.78, gogo (?), 20:49, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Квест - убей мой ССД )
Очевидно, что тут ССД отправляется на амбразуру обреченный, это суть данного метода. Но как-то жаль его....
| |
|
2.84, пох. (?), 00:16, 27/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
ты всегда можешь вставить его в рамочку и просто на него любоваться, если жаль.
Правда, придется подвести к ней питание - от висения на стене в рамочке выключенными - современные поделки умирают гораздо быстрее, чем от использования по назначению. Но судьба абсолютно любого ssd независимо от использования - умереть в помойке.
Ну и типа, вообще-то бывает и так:
Recommended: Cache drives should have high write endurance: at least 3 drive-writes-per-day (DWPD) or at least 4 terabytes written (TBW) per day
что для enterprise-grade железки ни разу не удивительно.
Это требования microsoft, если что.
| |
|
3.119, Аноним (-), 09:53, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Правда, придется подвести к ней питание - от висения на стене в
> рамочке выключенными - современные поделки умирают гораздо быстрее,
Ну а фигли, из мелких ячеек заряд утекает. И флеш превращается... превращается флеш... в подобие динамической оперативки, которой тоже регенерацию, дескать, подавай.
| |
|
4.133, kusb (?), 12:46, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
А ссд может быть средством для долговременного хранения данных более надёжным, чем магнитный диск? Диски же сыпятся, а тут может быть достаточно доставать раз в какое-то время, проводить регенерацию и снова ложить обратно. И с учётом этих мер всё дольше, чем диск. Или флешку вместо ссд.
| |
|
5.151, Аноним (151), 15:29, 27/05/2020 [^] [^^] [^^^] [ответить] | +2 +/– | Какой-нибудь старый SLC наверное может Но и цена за гигабайт там под стать А т... большой текст свёрнут, показать | |
|
|
|
|
1.91, iCat (ok), 04:54, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хм-м-м... А как поведёт себя подобная система в случае непрекращающегося потока изменений?
Предположим - высоконагруженная база данных, или, там, "видеопоток"?
| |
|
2.92, Аноним (92), 06:55, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Там же написано
> В случае отсутствия свободного места на прокси-диске все данные автоматически записываются в основное хранилище | |
|
1.96, Аноним (95), 07:43, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Квест - убей мой ССД )
Весь инет пестрит комментами в стиле - ха, проблема, куплю новый. Неужели не ваш случай?)
| |
|
2.103, пох. (?), 09:04, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | а вот это как раз вопрос отдельный - наш ли это случай, или заодно придется зано... большой текст свёрнут, показать | |
|
1.97, Аноним (95), 08:04, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> Когда Райзера выпустят, не раньше)
Пущай сидит этот подонок и сдохнет от спида коронного!
| |
1.123, Аноним (95), 10:14, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Да идеи то у него и тех кто рядом бывают неплохие. Но вот реализация... как обычно у россиян, своим путем и этот путь почему-то всегда ведет в один и тот же пункт, начинающийся на Ж :\
Вылезайте на свет божий, иначе так и не увидите, что ошибаетесь.Техологии идут в каждый дом, кто виноват, что вы сидите в Ж :\
| |
1.126, YetAnotherOnanym (ok), 11:11, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Добавление прокси-диска в логический том не сопровождается какой-либо перебалансировкой данных, а его удаление происходит точно так же, как и удаление обычного диска
Как это согласуется с тем, что на этом диске by design находятся данные, которых пока нет ни на одном другом диске?
| |
|
2.135, Аноним (153), 13:19, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> на этом диске by design находятся данные, которых пока нет ни на одном другом диске?
сам-то понял, что сказал?
| |
|
1.139, all_glory_to_the_hypnotoad (ok), 14:03, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> На данном же этапе ответственность за очистку возлагается на пользователя. Сброс данных с прокси-диска в основное хранилище производится простым вызовом утилиты...
Офигеть технологии, всё как всегда - через задницу. Если учесть, что под быстый диск будут выделять твёрдотельные накопители, то неплохо было бы все данные кодировать избыточно на несколько разных быстрых дисков и сбрасывать на медленные как можно быстрее. В предлагаемой архитектуре вся ФС может сдохнуть от частичной деградации быстрого диска с SSD.
Т.е. должен быть не просто сборос по крону, а специальный следящий за нагрузкой менеджер с приоритетами для метаданных.
| |
|
2.158, Аноним (158), 16:37, 27/05/2020 [^] [^^] [^^^] [ответить] | +/– | Не, ну блин, это все же честно обозначено как preview технологии И предъявлять ... большой текст свёрнут, показать | |
|
3.178, all_glory_to_the_hypnotoad (ok), 03:45, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Не, ну блин, это все же честно обозначено как preview технологии. И предъявлять при этом что-то довольно странно.
У этой технологии вроде как обозначен план развития и сделать хорошо в него не входит. Типа реализуем идею, которой 100 лет в обед, и посмотрим что делать дальше - так не работает. Надёжность технологии из-за SSD нужно продумывать сразу.
> Один маленький нюанс: минимальная конфига получится стоимостью как самолет.
Это всего лишь 2-3 SSD/NVMe, доступно многим любителям.
> А вот как эта штука с деградацией разбирается я не совсем понял. В теории вроде может записывать более 1 копии или RAID-like кодирование.
И с поблочными контрольными суммами (на каждые N KiB данных), просто RAID или копии будет мало.
| |
|
2.162, Аноним (39), 18:09, 27/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Т.е. должен быть не просто сборос по крону, а специальный следящий за нагрузкой менеджер с приоритетами для метаданных.
Сказали же: менеджер будет после достижения бета-стабильности. Было из-за чего визг поднимать. Просто так легче отлаживать.
| |
|
3.179, all_glory_to_the_hypnotoad (ok), 03:48, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Может быть, но есть подозрение что это будет чуточку продвинутый запуск предлагаемой команды по крону, а не полноценный планировшик перекачки. В тексте указано, что 'быстрый' диск для ФС выглядит как обычный, а для планировщика нужно ещё прицеплять некоторвые метаданные или даже иначе использовать дисковое пр-во.
| |
|
4.195, Аноним (153), 12:34, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> не полноценный планировшик перекачки
У тебя каша в голове. Зачем для очистки что-то планировать? На таргете создали копию, после этого удалили объект на исходном диске.
| |
|
5.197, all_glory_to_the_hypnotoad (ok), 14:22, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Конечный носитель может быть занят другим IO и если делать без планирования, то произойдёт размен отзывчивости ФС на быстрые burst write-ы. Для ФC честная отзывчивость (задержки) намного важнее быстрой записи. Т.е. где нужна быстрая запись приложения и так в состоянии нагородить свой лог.
| |
|
6.198, Аноним (153), 15:36, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Конечный носитель может быть занят другим IO и если делать без планирования, то произойдёт размен отзывчивости ФС на быстрые burst write-ы. Для ФC честная отзывчивость (задержки) намного важнее быстрой записи. Т.е. где нужна быстрая запись приложения и так в состоянии нагородить свой лог.
Тебе по ходу лечиться нужно.
| |
|
7.230, Аноним (230), 18:30, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Конечный носитель может быть занят другим IO
В той стратегии, что тут анонсирована, приложения напрямик не него не пишут. Только читают.
| |
|
8.239, Аноним (-), 10:21, 30/05/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Тупишь, тезка У господина теоретика там походу допущение что в целом IO - относ... текст свёрнут, показать | |
|
7.231, Аноним (231), 19:25, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Дело говорит. Только зачем мета-данные для планирования? Для этого нужна другая системная информация. С этой точки зрения диски равноправны.
| |
|
6.228, пох. (?), 16:22, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
гы/гы - угадай, на что напоролась ms, сделав аналогичную хрень в виде mirror+ec ;-)
У них все честно, никакого ручного переписывания.
| |
|
|
|
|
2.254, Crazy Alex (ok), 11:04, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Зачем такие извращения? Хочется дублирования - собери RAID и используй полученное устройство. А так - ну выдаст ошибку кэширующий диск - записать на основной.
| |
|
1.180, хотел спросить (?), 04:00, 28/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
сначала создаётся новый файл, который содержит изменённые данные;
потом этот новый файл записывается на диск при помощи fsync(2);
после этого новый файл переименовывается в старый, что автоматически освобождает блоки, занятые старыми данными.
что за бред? я таких СУБД не знаю...
| |
|
|
3.211, пох. (?), 08:48, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
+ sqlite в дефолтной (без WAL) конфигурации.
С WAL есть, э...особенности, поэтому по умолчанию он выключен - для тех кто о них не в курсе, лучше чтобы его не было.
| |
|
2.192, Аноним (192), 09:54, 28/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> что за бред? я таких СУБД не знаю...
Это не СУБД, это костыль под названием "безопасная перезапись файлов" на стороне программ, для ФС не умеющих в нормальное полноценное журналирование. Иначе при крахе в момент записи можно получить наполовину старый, наполовину новый файл. Который вовсе не обязан читаться программами.
А СУБД в силу таких свойств некоторых ФС с горя научились делать журналирование просто на своей стороне целиком.
| |
|
3.210, пох. (?), 08:46, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> для ФС не умеющих в нормальное полноценное журналирование
для всех.
> Иначе при крахе в момент записи можно получить наполовину старый, наполовину новый файл.
как журналирование от этого поможет?
В лучшем случае оно позволит избежать последствий reordering, когда мы писали-писали, решили что дописали, и поставили себе пометку transaction finished. Но головки стояли близко к журналу транзакций, и далеко от данных - поэтому система оптимизировала запись, первым записав что поближе, и тут ой, kernel panic.
journaled fs при этом не пометит запись состоявшейся уже на своем уровне - и при накате журнала запишет и данные, и метку заново, приведя все в консистентное состояние.
Но ценой потерь производительности на двойное (четверное) перезаписывание одного и того же.
Поэтому никто с journal=data и не хочет иметь дел.
Вот журналирующая CoW или log-structured (что совсем не то же самое) fs - поможет. Но опять же такой потерей производительности именно для субд - что все наизобретали костылей и подпорок, чтобы этот CoW для них выключать или хотя бы свести к минимуму.
При этом очевидный костыль вида полностью отключить внутреннее журналирование и direct io вместе с ним, и надеяться в этом на шибкопродвинутую fs - в случае как минимум mysql(innodb)+zfs не работает, данные первращаются в тыкву. Причины никому неизвестны и разбираться - героев не нашлось.
| |
|
4.218, Аноним (-), 10:20, 29/05/2020 [^] [^^] [^^^] [ответить] | +/– | На CoW получить старое состояние файла в случае не прокатило в принципе можно ... большой текст свёрнут, показать | |
|
5.225, all_glory_to_the_hypnotoad (ok), 13:47, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> На CoW получить старое состояние файла в случае "не прокатило" в принципе можно и без такой порнографии. Но тут смотря что программы делали.
CoW это метод оптимизации использования носителя, он не избавляет от необходимости делать новый файл с последующей подменой. Тем более для общего случая CoW вреден т.к. новый файл может измениться радикально для CoW.
> И будет файл с обломаной на середине записью, понятно насколько юзабельный.
Это может быть в любом случае, нельзя изменить любой файл за один write(...) с логом в ФС.
| |
|
6.237, Аноним (-), 09:20, 30/05/2020 [^] [^^] [^^^] [ответить] | +/– | А вообще мог бы В том плане что либо программа завершает запись и получает файл... большой текст свёрнут, показать | |
|
7.246, all_glory_to_the_hypnotoad (ok), 16:14, 30/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Не мог бы. Даже для такого варианта в ФС нужно заводить какой-нибудь теневой inode для удержания нового состояния, но в отличие от файла для работы с 'тенью' нужны отельные сущности внутри ФС и API. Хватит графоманить.
| |
|
|
5.226, пох. (?), 16:11, 29/05/2020 [^] [^^] [^^^] [ответить] | +/– | вопрос что такое старое состояние в случае begin set sum sum-b where id c s... большой текст свёрнут, показать | |
|
6.238, Аноним (215), 10:08, 30/05/2020 [^] [^^] [^^^] [ответить] | +/– | По логике вещей старое состояние - то что было до begin Новое - то что должно ... большой текст свёрнут, показать | |
|
7.243, пох. (?), 12:21, 30/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> По логике вещей: старое состояние - то что было до begin. Новое - то что должно стать после
> commit. Если удалось закрыть commit
проблема в том, что файловая система про это ничего не знает. Для нее (если бд просто косплеит sed, не добавляя собственные костыли и подпорки) это два последовательных write в разные места файла. (или двух разных, это тоже неизвестно)
Она не знает - будет за ними еще третий или четвертый, отдельны они от тех или их надо выполнять все сразу. Может только подождать их, на всякий случай, задержав операцию - если только специально не мешать.
Она может их переупорядочить, записав сначала второй потому что уже работала с соседним сектором по другой задаче.
Ни cow, ни журнал тут не помогут - они работают на уровне блоков.
Для "обычной" работы с файлами на это можно наплевать, просто гарантировать консистентность fs (не файла) при любых условиях, и файла - после подтвержденного закрытия или при работе в append-only mode. (если мы потеряли или повредили редактируемый файл - это то чего и следовало ожидать, ничего страшного в этом нет) Но для БД это фатально.
Единственный вариант - выносить транзакции на уровень fs. Но в posix такого не предусмотрено.
| |
|
8.250, Аноним (250), 22:58, 30/05/2020 [^] [^^] [^^^] [ответить] | +/– | Ну вот я не вижу причин по которым нельзя было бы информировать ее немного больш... большой текст свёрнут, показать | |
|
|
|
|
|
|
2.224, all_glory_to_the_hypnotoad (ok), 13:40, 29/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это не для СУБД. Простая задача: нужно вставить строчку в текстовый конфиг не испортив конфиг при всех возможных сценариях работы вставки. Для in-place операции нужно переписать часть файла - от вставляемой строчки и до конца. Если операция оборвётся до завершения, то файл может остаться в невалидном состоянии. Единственное решение это написать рядом новый файл и подменить им старый.
Практически никакие форматы данных не поддерживают атомарные in-place изменения, известные исключения это записть в конец лога и файлы данных СУБД.
Ниакие фичи ФС (журналирование данных, CoW...) не решают проблему, некоторые пользователи выше написали кучу ерунды на этот счёт.
| |
|
3.227, пох. (?), 16:18, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Практически никакие форматы данных не поддерживают атомарные in-place изменения, известные
> исключения это записть в конец лога и файлы данных СУБД.
у СУБД ровно те же проблемы. Ей не надо переписывать весь файл, но ей надо изменить его сразу в нескольких местах (и еще пяток других файлов, если индексы лежат где-то отдельно).
Причем, в отличие от конфига, места для второй копии этого файла может вообще не быть на диске.
Фичи fs тут не то что не решают проблему, а создают новые.
| |
|
4.229, all_glory_to_the_hypnotoad (ok), 17:33, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
У полноценной СУБД с in-place модификацией такой проблемы нет ибо форматы файлов данных и протокол использования позволяют определить и откатить неполные изменения. Есть СУБД без in-place операций с пеписыванием файлов данных, для этого всего лишь достаточно делать мн-во небольших файлов.
По сути в СУБД первого типа тоже нет in-place модификаций, внутри всё равно делают копии кусков данных с заменой ссылок на новые блоки.
| |
|
|
|
|