И
кто то подключал ovh vrack?
А что с ним не так ?
Size: a a a
2020 October 23
Д
при переполнении места в мете всё встанет. или, если верить некоторым товарищам, даже данные полностью могут потеряться.
Как-то очень ненадежно. Очень стремно звучит, что из-за переполнения места в мете, теряются данные.
Народ кто-то может подтвердить, что данные теряются?
Народ кто-то может подтвердить, что данные теряются?
I
Как-то очень ненадежно. Очень стремно звучит, что из-за переполнения места в мете, теряются данные.
Народ кто-то может подтвердить, что данные теряются?
Народ кто-то может подтвердить, что данные теряются?
у меня было переполнение один раз, но данные не терялись. нужно просто заранее расчитывать размер чанка под планируемый объём данных и переполнение не грозит.
Д
у меня было переполнение один раз, но данные не терялись. нужно просто заранее расчитывать размер чанка под планируемый объём данных и переполнение не грозит.
А как решил проблему переполнения?? Увеличил раздел мета?
I
А как решил проблему переполнения?? Увеличил раздел мета?
да. но его максимальный размер 16г.
I
а при таких жирных дисках, мб тонкие диски и не нужны ?
I
советую обычный лвм.
СГ
Как-то очень ненадежно. Очень стремно звучит, что из-за переполнения места в мете, теряются данные.
Народ кто-то может подтвердить, что данные теряются?
Народ кто-то может подтвердить, что данные теряются?
я думаю что Иван немного перебарщивает)) со страшилками. LVM - один из типов стораджей, которые уже давно используются в проксе
Д
я думаю что Иван немного перебарщивает)) со страшилками. LVM - один из типов стораджей, которые уже давно используются в проксе
Какой вы порекомендуете тип LVM использовать для хранения ВМ?
I
я думаю что Иван немного перебарщивает)) со страшилками. LVM - один из типов стораджей, которые уже давно используются в проксе
я обрисовал риски )
СГ
Какой вы порекомендуете тип LVM использовать для хранения ВМ?
я бы порекомендовал zvol, но если выбор между LVM и Thin LVM, то обычный
Д
я бы порекомендовал zvol, но если выбор между LVM и Thin LVM, то обычный
Почему обычный?
I
еще я один раз терял данные из-за включенного кэша записи при потере питания. и вот когда побилось пару килобайт на обычных данных это не так заметно, а в мете эта проблема как бы мультиплицируется и теряется инфы в разы больше. но тут кагбе уже разница небольшая - всёравно данные побиты. просто не надо юзать незащищенный кэш.
СГ
Почему обычный?
вот как раз чтобы не переживать из-за проблем с нехваткой места под мету
I
благо всё это происходило на тестовом сервере ))
Д
еще я один раз терял данные из-за включенного кэша записи при потере питания. и вот когда побилось пару килобайт на обычных данных это не так заметно, а в мете эта проблема как бы мультиплицируется и теряется инфы в разы больше. но тут кагбе уже разница небольшая - всёравно данные побиты. просто не надо юзать незащищенный кэш.
Ну с кэшем все понятно. Тут питание отвалилось и данные на диск физически не записались. Но с thin lvm это же не так происходит
I
tldr: обычный lvm - сколько места под диски вм дашь, столько и занято будет.
тонкий lvm - занимает место по мере заполнения дисков вм данными.
тонкий lvm - занимает место по мере заполнения дисков вм данными.
I
Ну с кэшем все понятно. Тут питание отвалилось и данные на диск физически не записались. Но с thin lvm это же не так происходит
когда получается так, что софт думает что данные записались, а на самом деле нет и потом этих данных не обнаруживается,происходят нехилые повреждения данных.
I
повреждения с точки зрения по и фс
Д
когда получается так, что софт думает что данные записались, а на самом деле нет и потом этих данных не обнаруживается,происходят нехилые повреждения данных.
поэтому я не использую кэши отложенной записи