Anonymous

дело в том что на btrfs и ZFS данные пишутся одновременно и в журнал и на сам диск.

Mark ☢️

а что, есть долбаеб использующий это с цефом ?

Anonymous

а на xfs,ext4 вначале в журнал, а потом max_sync_interval срабатывает и пишется через syncfs. ну а syncfs вызывает sync

Anonymous

но один хрен блокировка возникает, но клиенту уже отдается ask при записи в журнал

Anonymous

а что, есть долбаеб использующий это с цефом ?

на тестовых лабах почему бы и нет :)

Mark ☢️

попробуй на FAT32

Mark ☢️

или NTFS

Mikhail

да вроде были люди, кто юзал btrfs

Anonymous

ну точно не на проде

Mike

дело в том что на btrfs и ZFS данные пишутся одновременно и в журнал и на сам диск.

Да, ебать, и это их фишка, так же описанная в доке. Читать надо документацию.

Mike

И, кстати, для записи в журнал не используется posix io. Используется libaio

Mike

а что, есть долбаеб использующий это с цефом ?

Резон есть. Btrfs, например, сверяет контрольную сумму блока при чтении, чего не делает сам ceph. Потоковая запись на btrfs - быстрее.

Anonymous

И, кстати, для записи в журнал не используется posix io. Используется libaio

не-не, я про сам стандарт Posix IO имел ввиду, а не про Posix AIO.

Евгений

Вброшу: Берём N+1 консьюмерских cloud-provider'ов. Поднимаем на их базе файловые системы. Можно уровня fuse для swift'а, т.е. object-based. На базе этих файловых систем поднимаем ceph с mon'ами на своём компьютере и нескольких заныканных виртуалочках вокруг. Дальше с этим можно работать как с _надёжным_ блочным или файловым устройством. Например, хранить собственные данные в таком виде, чтобы ни один провайдер не мог оставить вас без этих данных. Если один из osd - локальный, то получаем лучшее от всех миров: локальную оффлайновую доступность, репликацию в безопасные независимые облака. (c) amarao

Александр

амарао реплицировал-реплицировал, да не выдреплицировал

Mikhail

ну да, отличное решение - все будет и скорость записи и надежность )

Mark ☢️

Вброшу: Берём N+1 консьюмерских cloud-provider'ов. Поднимаем на их базе файловые системы. Можно уровня fuse для swift'а, т.е. object-based. На базе этих файловых систем поднимаем ceph с mon'ами на своём компьютере и нескольких заныканных виртуалочках вокруг. Дальше с этим можно работать как с _надёжным_ блочным или файловым устройством. Например, хранить собственные данные в таком виде, чтобы ни один провайдер не мог оставить вас без этих данных. Если один из osd - локальный, то получаем лучшее от всех миров: локальную оффлайновую доступность, репликацию в безопасные независимые облака. (c) amarao

Чессказать нихуя не понял

Евгений

Чессказать нихуя не понял

покупаем пельмени.... варим....

Anonymous

...и не кушаем эти пельмени )

Mark ☢️

А как же сварочник ?

Евгений

...и не кушаем эти пельмени )

нет, вареные продаем на рынке за те же деньги, за которые купили оригинал, а бульончик сливаем к себе!

Евгений

идея такая - к себе монтируем несколько ФС

Евгений

потом у себя сверху этих фс поднимаем осд с файлсторами

Евгений

дальше - профит

Mark ☢️

Этакий цеф из цефов

Sn00part

да проще на перфокартах выбить и не париться

Sn00part

быстрее будет

Anonymous

@Lumen_Ratio

Anonymous

специально для тебя: https://www.spinics.net/lists/ceph-devel/msg06177.html

Artem

Всем привет! Прошу объяснить простую вещь, залили 1.6 Тб на диск, после выполнили rm -rf * Ceph место не освободил, собственно, что сделать чтобы он понял, что все потерли?

Anonymous

Включить trim

Artem

А для rbd это нормально? Я думал он сам как то это понимает

Anonymous

Да это нормально поведение, для всех схд. Из-за этого и придуман trim

Artem

А если я сверху 1.6 терабайта заливаю, он данные перезаписывает или снова кладет? Ну то есть понятно что с обычным HDD, он перезаписывает поверх, а что делает rbd?

Anonymous

Будет такое же поведение

Anonymous

Перезапишет тоесть.

Anonymous

Сам размер диска сколько?

Artem

2Тб

Anonymous

Новые данные размажет ещё на +400 гигов. Но это от фс внутри виртуалки зависит

Artem

Я просто наблюдаю за ceph -w там место уменьшается с процессом накопирования данных, причем примерно так было 4582 стало 4577 Скопировано 4,6Gb

Anonymous

Репликации ещё имеются :)

Artem

Новые данные размажет ещё на +400 гигов. Но это от фс внутри виртуалки зависит

Ну в общем ладно, спасибо за разъяснение завтра с утра проверю, надеюсь не увижу, что место кончилось =(

edo1

В тему двойной записи и блюстора: зато сейчас есть возможность хранить журнал на ssd, получается (почти) бесплатный wb кэш

edo1

С новым хранилищем такого не будет, увы

J

С новым хранилищем такого не будет, увы

Будет если сам сделаешь. dm-cache, bcache, flashcache.

Mark ☢️

В тему двойной записи и блюстора: зато сейчас есть возможность хранить журнал на ssd, получается (почти) бесплатный wb кэш

Это и до блюстора было

Mark ☢️

С новым хранилищем такого не будет, увы

С блюстором тюница чио сувать в журнао а что нет

edo1

Это и до блюстора было

я про то и писал, что ДО блюстора можно было просто положить лог на ssd

edo1

где тюнится? как тюнится?

Mark ☢️

https://www.google.ru/url?sa=t&source=web&rct=j&url=http://events.linuxfoundation.org/sites/events/files/slides/20170323%2520bluestore.pdf&ved=0ahUKEwiviMiv3bbVAhXLA5oKHWR0AZAQFggcMAA&usg=AFQjCNGuJ3P_UICVKZHTG2crNPZCnOdoyg

Anonymous

у меня тут какой-то цирк с PG:

Anonymous

3.88d undersized+degraded+remapped+backfill_wait+peered [69,6,24] 69 [0] 0 3.36e undersized+degraded+remapped+backfill_wait+peered [71,4,37] 71 [46] 46 3.192 undersized+degraded+remapped+backfill_wait+peered [67,14,27] 67 [45] 45 3.c80 undersized+degraded+remapped+backfill_wait+peered [62,76,44] 62 [45] 45 3.204 undersized+degraded+remapped+backfill_wait+peered [75,52,1] 75 [45] 45 что в таком случае делать?

Евгений

recovery идет?

Anonymous

блин, идет

Anonymous

только не на тех пг (там добавляли осд, и еще куча всего в бэкфил_вейт)

Anonymous

как-то можно сказать что именно эти 5 пг надо залить в первую очередь?

Anonymous

каким _вообще_ образом при всех целых OSD они оказались в peered? (= меньше min_size?)

Anonymous

похоже на баг ceph-osd, постмортем будет завтра