The OpenNET Project / Index page

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

В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering)

26.05.2020 13:14

Эдуард Шишкин анонсировал новые возможности, развиваемые в рамках проекта Reiser5. Reiser5 представляет собой существенно переработанный вариант файловой системы ReiserFS, в котором на уровне файловой системы, а не блочного устройства, реализована поддержка параллельно масштабируемых логических томов, позволяющая эффективно распределять данные по логическому тому.

Из развиваемых в последнее время новшеств отмечается предоставление пользователю возможности добавить небольшое высокопроизводительное блочное устройство (напр. NVRAM), называемое прокси-диском, к относительно большому логическому тому, скомпонованному из медленных бюджетных дисков. При этом будет создаваться впечатление, что весь том скомпонован из таких же дорогостоящих высокопроизводительных устройств, как и "прокси-диск".

В основу реализованного метода легло простое наблюдение, что на практике запись на диск не ведётся постоянно, а кривая нагрузки ввода-вывода имеет форму пиков. В промежутке между такими "пиками" всегда имеется возможность сбросить данные с прокси-диска, переписав в фоновом режиме все данные (или же только часть) в основное, "медленное" хранилище. Таким образом, прокси-диск всегда готов к приёму новой порции данных.

Изначально данная техника (известная как Burst Buffers) возникла в области высокопроизводительных вычислений (HPC). Но она оказалась также востребованной и для обычных приложений, особенно для тех, которые предъявляют повышенные требования к целостности данных (обычно это разного рода базы данных). Любые изменения в каком-либо файле такие приложения выполняют атомарным способом, а именно:

  1. сначала создаётся новый файл, который содержит изменённые данные;
  2. потом этот новый файл записывается на диск при помощи fsync(2);
  3. после этого новый файл переименовывается в старый, что автоматически освобождает блоки, занятые старыми данными.

Все эти шаги в той или иной степени становятся причиной существенного снижения производительности на любой файловой системе. Ситуация улучшается, если новый файл сначала записать на выделенное высокопроизводительное устройство, что в точности и происходит в файловой системе с поддержкой "Burst Buffers".

В Reiser5 планируется опционально отправлять на прокси-диск не только новые логические блоки файла, но и все грязные страницы вообще. Причём, не только страницы с данными, но также и с мета-данными, которые записываются на шагах (2) и (3).

Поддержка прокси-дисков осуществляется в контексте штатной работы с логическими томами Reiser5, анонсированной в начале года. То есть, совокупная система "прокси-диск - основное хранилище" является обычным логическим томом с той лишь разницей, что прокси-диск имеет приоритет среди остальных компонетнов тома в политике выделения дисковых адресов.

Добавление прокси-диска в логический том не сопровождается какой-либо перебалансировкой данных, а его удаление происходит точно так же, как и удаление обычного диска. Все операции с прокси-диском атомарны. Обработка ошибок и развёртывание системы (в т.ч. после системного краха) происходит точно так же, как если бы прокси-диск был обычным компонентом логического тома.

После добавления прокси-диска, суммарная ёмкость логическгого тома увеличивается на ёмкость этого диска. Мониторинг свободного места на прокси-диске производится так же, как и для остальных компонентов тома, т.е. при помощи утилиты volume.reiser4(8).

Прокси-диск необходимо периодически очищать, т.е. сбрасывать данные с него в основное хранилище. После достижения бета-стабильности Reiser5 очистку планируется сделать автоматической (ей будет заведовать специальный поток ядра). На данном же этапе ответственность за очистку возлагается на пользователя. Сброс данных с прокси-диска в основное хранилище производится простым вызовом утилиты volume.reiser4 с опцией "-b". В качестве аргумента нужно указать точку монтирования логического тома. Разумеется, очистку надо не забывать проводить периодически. Для этого можно написать простой shell-скрипт.

В случае отсутствия свободного места на прокси-диске все данные автоматически записываются в основное хранилище. При этом по умолчанию снижается общая производительность ФС (из-за постоянного вызова процедуры коммита всех имеющихся транзакций). Опционально можно задать режим без потери производительности. Однако, в этом случае дисковое пространство прокси-устройства будет использоваться менее эффективно. В качестве прокси-диска удобно использовать подраздел (брик) мета-данных, при условии, что он создан на достаточно высокопроизводительном блочном устройстве.

  1. Главная ссылка к новости (https://marc.info/?l=reiserfs-...)
  2. OpenNews: Доступна файловая система Reiser5
  3. OpenNews: В файловой системе Reiser4 появилась поддержка зеркалирования
  4. OpenNews: Обновление файловой системы Reiser4 c поддержкой различных транзакционных моделей
  5. OpenNews: Стагнация в продвижении Reiser4 в состав ядра Linux
  6. OpenNews: Состояние разработки Reiser4
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53027-reiser5
Ключевые слова: reiser5, reiserfs
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (242) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 14:08, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Когда в ядро?
     
     
  • 2.3, Страдивариус (?), 14:11, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Когда Райзера выпустят, не раньше)
     
     
  • 3.4, Аноним (1), 14:24, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А его не отпустили разве из-за коронавируса? Где-то пробегало вроде.
     
     
  • 4.16, llolik (ok), 14:53, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Где-то пробегало вроде.

    В шутках на первое апреля

     
  • 4.19, бублички (?), 15:07, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +18 +/
    выгнали из тюрьмы, за плохое поведение
     
     
  • 5.52, Kuromi (ok), 18:19, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    клацанием по клавиатуре сокамерникам спать мешал...
     
     
  • 6.53, Вы забыли заполнить поле Name (?), 18:27, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ему комп не дают (хотя он вроде просил), поэтому он ботает физику.
     
     
  • 7.164, evgeniy (??), 18:18, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пусть пишет на туалетной бумаге, потом перенесет
     
  • 4.51, pda (?), 18:10, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У него было слушание в марте об условно-досрочном. Насколько я помню не выпустили.
     
     
  • 5.54, Вы забыли заполнить поле Name (?), 18:28, 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 +/
    Коливас -- отвратительный сверхтоксичный человек, и код его глючный и безграмотный. Так что не удивительно. Но вот ведь, запихнули в ядро.
     
     
  • 4.12, Аноним (1), 14:48, 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, конечно. Что довольно странная идея - платить фирме за их баги.

     
     
  • 8.242, Аноним (153), 11:35, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Платить надо было за вытаскивание данных с побитого железа Во всех остальных сл... текст свёрнут, показать
     
     
  • 9.248, Аноним (248), 21:01, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот лично я c ext4 допустим могу вынуть данные и без всего этго Даже с основ... большой текст свёрнут, показать
     
  • 5.35, Аноним (35), 16:10, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • –7 +/
     
     
  • 6.45, Аноним (45), 17:36, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • –6 +/
     
     
  • 7.61, Аноним (7), 19:27, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 8.63, Аноним (63), 19:41, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 9.67, Аноним (7), 19:57, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 10.113, Аноним (-), 09:39, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 11.205, Аноним (205), 02:00, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 12.207, Аноним (-), 07:09, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 13.221, Аноним (221), 11:35, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 10.115, псевдонимус (?), 09:42, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 11.183, Аноним (-), 08:20, 28/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 12.206, Аноним (205), 02:01, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 13.208, Аноним (-), 07:13, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 14.222, Аноним (221), 11:44, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 9.93, Tifereth (ok), 07:09, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 10.111, zzz (??), 09:26, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +6 +/
     
     
  • 11.114, Аноним (-), 09:41, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 12.163, Школьник (ok), 18:12, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 13.184, Аноним (-), 08:21, 28/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 14.193, Аноним (-), 11:23, 28/05/2020 Скрыто ботом-модератором     [к модератору]
  • +3 +/
     
     
  • 15.209, Аноним (209), 07:31, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 16.223, Аноним (223), 12:55, 29/05/2020 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 12.177, Аноним (177), 02:49, 28/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 13.185, Аноним (-), 08:26, 28/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 10.194, Аноним (-), 12:08, 28/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 7.69, Аноним (35), 20:00, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 8.105, Аноним (-), 09:09, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 7.79, пох. (?), 21:32, 26/05/2020 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     
  • 7.129, Аноним (129), 12:30, 27/05/2020 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 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)"
     
     
  • 5.77, Аноним (1), 20:38, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Из морозильника вылезай уже https://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDM Ему про дистрибутив, а он про ведро всё талдычет.
     
     
  • 6.83, Аноним (35), 22:31, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тормоз, в последней ubuntu reiserfs не удалили, а ты ссылку 2013 года кидаешь. Мозги совсем в студень превратились?
     

     ....большая нить свёрнута, показать (59)

  • 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 в принципе уметь не может.
     
  • 2.14, Минона (ok), 14:50, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    они реализовали zlog из ZFS
     
     
  • 3.23, Аноним (21), 15:15, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по описанию - нечто явно круче чем это.
     
     
  • 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 ничего не знают от слова совсем.

     
     
  • 5.121, Crazy Alex (ok), 10:07, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А пик IO-load - это что, по вашему, как не большой объём ввода-вывода?
     

  • 1.9, Аноним (9), 14:35, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Эдуард Шишкин анонсировал

    Ну а толку то, оно же не в ядре. А Шишкину западло заниматся багами.

     
     
  • 2.11, Аноним (153), 14:40, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну а толку то, оно же не в ядре

    Ну и что? ZFS тоже не в ядре.

     
     
  • 3.24, Аноним (21), 15:16, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так он и является в лине куском головняка. За что и умрет.
     
     
  • 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.80, Аноним (80), 21:32, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >zfz
    >inux
    >надёжность

    Как говорится, выберите любые 2!

     
  • 6.125, Аноним (125), 10:59, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А в чем выражается ненадежность ZFS на Linux? На моем домашнем насе переехал с фряхи на дебиан ради привычного окружения, за год не видел пока никаких проблем. Что ожидает?
     
     
  • 7.127, Аноним (7), 11:31, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я знаю только о ненадёжности на эксбсд на домашних подкраватных полках она расс... большой текст свёрнут, показать
     
     
  • 8.136, Аноним (125), 13:29, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Что подразумеваешь под эксбсд Использование на системах, отличных от bsd, ил... текст свёрнут, показать
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Блин, пох, я тебе сразу сказал что все это будет работать так И убунта тут не п... большой текст свёрнут, показать
     
     
  • 8.214, Аноним (213), 09:32, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    p s еще кстати могут влепить прямо в железо, так намного прикольнее И даже вро... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (17)

  • 1.26, Аноним (26), 15:22, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > В основу реализованного метода легло простое наблюдение, что на практике запись на диск не ведётся постоянно, а кривая нагрузки ввода-вывода имеет форму пиков. В промежутке между такими "пиками" всегда имеется возможность сбросить данные с прокси-диска, переписав в фоновом режиме все данные (или же только часть) в основное, "медленное" хранилище. Таким образом, прокси-диск всегда готов к приёму новой порции данных.

    Шишкин переизобрел SSHD?

     
     
  • 2.37, Аноним (35), 16:13, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Такими темпами в линуксе все те возможности которые давно есть в ntfs появятся лет через 20
     
     
  • 3.38, Аноним (35), 16:15, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    позорище, в 2020 линуксоиды изобрели ReadyBoost
     
     
  • 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 +/
    > Т.е. по сути просто реализована поддержка кэширования записи на быстрый диск?

    Нет там никакого кэширования. Там миграция. Кэширование - это "и там и тут". Миграция - это "или там, или тут".

     
     
  • 3.56, Аноним (56), 18:50, 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, блин, но велосипед, конечно, зачотный.

     
     
  • 4.134, Аноним (129), 12:59, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А smartdrv в MSDOS это не про сжатый диск?
     
     
  • 5.141, СеменСеменыч777 (?), 14:31, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сжатый диск в MS DOS это Stacker.

     
  • 5.142, Аноним (-), 14:35, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А smartdrv в MSDOS это не про сжатый диск?

    Нет, это кэш отложенной записи, многократно разгонявший скорость записи на винч. Про сжатие DoubleSpace и DriveSpace (dblspace и drvspace) были. В линухе вроде даже была поддержка, которую если не ошибаюсь, не так давно выкинули как раз - т.к. походу юзеров этого на глобусе тупо не осталось.

     
     
  • 6.200, СеменСеменыч777 (?), 19:32, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    оказывается, там были разборки такие:
    https://en.wikipedia.org/wiki/Stacker_(disk_compression)#Microsoft_lawsuit
     
  • 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 диск и пойнт этого начинания. Если это какой-то иной диск, то это совсем другой вопрос.

    Изначальный вопрос был про тестирование. Для этого достаточно обойтись лишь рамдиском. Для
    серьёзных целей, разумеется, придётся прикупить память на батарейках.

     
  • 4.204, microsoft (?), 22:54, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то мы уже давно умеем кэшировать на ssd/nvme (и даже на pram, но это неточно).

    https://www.starwindsoftware.com/blog/why-you-should-consider-storage-spaces-d

    - похоже, это и послужило источником вдохновения мистеру Шишкину?

    Но, обратите внимание -  у нас fs не превратится в тыкву, если отвалится один ssd. А вы так можете?

     
  • 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... большой текст свёрнут, показать
     
     
  • 8.159, Аноним (7), 16:37, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Обычно цель всё же не живучесть и способность загрузиться на убитой флешке, дост... текст свёрнут, показать
     
     
  • 9.165, Аноним (-), 18:24, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как по мне - это вполне хорошая и правильная цель, экономящая немало нервных кле... большой текст свёрнут, показать
     
  • 2.46, Аноним (153), 17:41, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем этот уровень внутри файловой системы, а не блочного устройства?

    У блочного уровня плохая масштабируемость.
    Вот тут подробно разжёвываются недостатки блочного уровня:
    https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Background

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Это абстрактное заявление, ничего не говорящее сколько операций в единицу времен... большой текст свёрнут, показать
     
     
  • 8.196, Аноним (153), 13:17, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Иди, расскажи Молнару и Торвальдсу, что их O 1 -планировшщик ничего не говорит,... текст свёрнут, показать
     
     
  • 9.216, Аноним (215), 09:47, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Эм это им успешно рассказывают форониксы, коливасы и прочие гентушники ... текст свёрнут, показать
     
     
  • 10.219, Аноним (39), 10:24, 29/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! (автырь переколпачивает или странно юзает значения половины слов).

     
     
  • 8.199, Аноним (153), 18:02, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Всё там чётко и без противоречий Иди учи английский ... текст свёрнут, показать
     
     
  • 9.217, Аноним (215), 09:50, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Особенно определение, противоречащее смыслу английских слов в нем D Походу это ... текст свёрнут, показать
     
     
  • 10.220, Аноним (39), 11:12, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И какому же слову в нём, как вы изволили выразиться, оно противоречит Слово в с... текст свёрнут, показать
     
     
  • 11.232, Аноним (-), 22:27, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Parallel Определение Parellel scaling out там просто эпик какой-то, из формальн... текст свёрнут, показать
     
     
  • 12.233, Аноним (39), 00:49, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В той статье из вики есть предыстория Previous Art , из которой становится поня... большой текст свёрнут, показать
     
     
  • 13.236, Аноним (-), 08:59, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да Там это написано более логично Однако определить parallel через saves... большой текст свёрнут, показать
     
     
  • 14.244, Аноним (153), 13:14, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно путать block-level и block layer block layer - этот подсистема O... текст свёрнут, показать
     
  • 14.245, Аноним (39), 14:22, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В классической логике очень даже корректно Почитай определение параллельности, ... текст свёрнут, показать
     
     
  • 15.247, Аноним (247), 17:11, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Параллельные прямые у Лобачевского пересекаются это что-то новое Очень желаю ув... текст свёрнут, показать
     
     
  • 16.249, Аноним (39), 22:56, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо, не у него а обидно Ключевое слово пересекаются С этим нет вопросо... текст свёрнут, показать
     
     
  • 17.251, Аноним (251), 00:05, 31/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Даже как то странно взрослым людям напоминать что это определение параллельных ... текст свёрнут, показать
     
     
  • 18.252, Аноним (153), 03:16, 31/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ни в одной геометрии не пересекаются Ох ты ж господи Пресекаются прямые, е... текст свёрнут, показать
     
     
  • 19.253, Аноним (253), 11:02, 31/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты к другому анониму иди за английский язык тереть Мне достаточно того что ... текст свёрнут, показать
     
  • 12.234, Аноним (153), 02:26, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    То есть, тебе непонятно, почему Шишкин определяет параллельность через сохранени... текст свёрнут, показать
     
     
  • 13.235, Аноним (-), 08:02, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По нему заметно И это может быть и работает для какой-нибудь абстрактной ма... большой текст свёрнут, показать
     
     
  • 14.241, Аноним (153), 11:16, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Объяснять суть своих открытий окружающим - это решительно не дело учёных Для эт... текст свёрнут, показать
     
  • 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 лет к ряду с калом вместо пакетного менеджера - не больно какой стандарт качества.

     

     ....большая нить свёрнута, показать (54)

  • 1.43, Thony (?), 17:23, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Идея с прокси-диском в составе тома прикольная, но, к примеру, что если некоторые файлы мне хочется постоянно иметь в быстром доступе? Поди придумает атрибуты для каталога?
     
     
  • 2.47, Нолекс (?), 17:43, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хранить на отдельном томе без прокси не вариант?
     
  • 2.49, Аноним (153), 17:55, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > что если некоторые файлы мне хочется постоянно иметь в быстром доступе?

    Я так понимаю, что с этим проблем не возникнет. Присвой им максимально высокое значение
    "температуры", и сканнер не будет их трогать. Шишкин говорил, что нет пока алгоритмов для
    определения критической температуры, всё что ниже которой выгоняется с прокси.

     

  • 1.50, Eric Hartman (?), 17:55, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть у неё какие-нибудь плюшки для SSD?
     
     
  • 2.149, Аноним (148), 15:15, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть у неё какие-нибудь плюшки для SSD?

    Ну вот плюшка юзать SSD для затыкания амбразуры^W^W обеспечения быстрой записи по всей площади большого диска.

     

  • 1.55, Аноним (55), 18:34, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Уже есть zfs, bcache и lvmcache
     
     
  • 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... :)

     

  • 1.64, Аноним (64), 19:53, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждём поддержку райзер5 в ядре.
     
  • 1.65, Аноним (64), 19:54, 26/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, почему Эдуард не переименовывает проект?
     
     
  • 2.74, Михрютка (ok), 20:19, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    он боится, что shishkinfs русские будут писать на опеннете сиськинфс, а американцы на каком-нибудь реддите - shitkinfs
     
     
  • 3.76, Аноним (64), 20:32, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но ведь я уже сейчас могу написать срайзерфс...
     
  • 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.86, Аноним (86), 01:54, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не перевелись ещё гении на земле Русской, коим Эдуард и является!
     
  • 1.91, iCat (ok), 04:54, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм-м-м... А как поведёт себя подобная система в случае непрекращающегося потока изменений?
    Предположим - высоконагруженная база данных, или, там, "видеопоток"?
     
     
  • 2.92, Аноним (92), 06:55, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Там же написано

    > В случае отсутствия свободного места на прокси-диске все данные автоматически записываются в основное хранилище

     

  • 1.94, Аноним (94), 07:31, 27/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Свободу разрабам!
     
  • 1.95, Аноним (95), 07:40, 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 находятся данные, которых пока нет ни на одном другом диске?

    сам-то понял, что сказал?

     
     
  • 3.140, YetAnotherOnanym (ok), 14:31, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > сам-то понял, что сказал?

    Я - да, а ты?

     

  • 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);
    после этого новый файл переименовывается в старый, что автоматически освобождает блоки, занятые старыми данными.


    что за бред? я таких СУБД не знаю...

     
     
  • 2.191, Аноним (191), 09:23, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    mysql trx 1
     
     
  • 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 модификаций, внутри всё равно делают копии кусков данных с заменой ссылок на новые блоки.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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