The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Оценка методов противостояния потере данных в ФС при крахе с..., opennews (??), 15-Дек-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


58. "Оценка методов противостояния потере данных в ФС при крахе с..."  –2 +/
Сообщение от Чаёвник (?), 15-Дек-15, 17:39 
Это у чувака из сабжа ещё при пропадании света флешпамять и всякие SSDы не сдыхали, то-то он удивится.

У каких ФС есть снапшоты и шифрование без костылей а ля "смонтируйте поверх ста прокладок"?
А так же возможность сменить столетний пароль на зашифрованном томе, не потеряв успешно все данные на оном?

Ответить | Правка | Наверх | Cообщить модератору

61. "Оценка методов противостояния потере данных в ФС при крахе с..."  –2 +/
Сообщение от Анонимemail (1), 15-Дек-15, 17:45 
Ответ очевиден -> http://www.oracle.com/technetwork/articles/servers-storage-a...

Больше нет ничего, а под линуксом в ближайшие лет 20 ничего ждать не стоит.

Ответить | Правка | Наверх | Cообщить модератору

66. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Чаёвник (?), 15-Дек-15, 19:46 
Ответ не очевиден, т.к. шифрования в открытых реализациях ZFS до сих пор нет, это весьма печалит. Если кто в теме "до коле", было бы интересно узнать.
Пользовал активно UFS2+SU, UFS2 SU+J, ZFS (в т.ч. на x86), вполне нормальные ФС, не знаю чего у всех так бомбит. В этом плане Sabayon смотрится весьма интересно, с одной стороны он source based, с другой у него заявлена поддержка ZFS из коробки, но качество пока хромает :(
Ответить | Правка | Наверх | Cообщить модератору

143. "Оценка методов противостояния потере данных в ФС при крахе с..."  +2 +/
Сообщение от Аноним (-), 16-Дек-15, 15:04 
Критерий "нормальности" - уж очень растяжимая вещь. Много чего поюзать пришлось, так самая надёжная фс - это как раз ext4. UFS2, на бзде, своим развалом при выключении питания/остановке ВМ - слишком рискованная вещь, чтобы в ней вообще хранить данные. ZFS на линуксе - тоже хорошо себя показала.
Всё познаётся в сравнении.
Ответить | Правка | Наверх | Cообщить модератору

148. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Чаёвник (?), 16-Дек-15, 15:39 
UFS2 SU+J очень сложно развалить. Тут очень интересно было бы статистику в сравнении с Ext4
Ответить | Правка | Наверх | Cообщить модератору

153. "Оценка методов противостояния потере данных в ФС при крахе с..."  +2 +/
Сообщение от Аноним (-), 16-Дек-15, 18:21 
Упрощённая статистика:
- ехt4 - за годы её существования никогда не падала. Линукс-машины выключались, виртуалки стопались. Я их не жалею, ибо fsck всё поправит.
- ext2,3 - при мне - тоже почти никогда. Был только случай потери данных из-за падения жёсткого диска на каменный пол.
- UFS-2 - падала всего лишь сотни раз. На разном железе и виртуалках. Основная причина - некорректное завершение работы. Данные терялись из-за недосинка. ФС терялась из-за отказа fsck. Возможно, если бы всё всегда выключалось корректно, то этого бы не происходило, но, я не могу позволить себе корректно гасить тысячи ВМ, несколько из которых были на бзде.
- NTFS - падала десятки раз(я с вантузом очень давно ковырялся. Сейчас уже не могу оценить), перемешивались данные между файлами, фрагментированные тормоза, превращение блочного устройства в нечитаемое месиво(как из-под вантуза, так и из-под линукса)
Ответить | Правка | Наверх | Cообщить модератору

155. "Оценка методов противостояния потере данных в ФС при крахе с..."  –2 +/
Сообщение от Чаёвник (?), 16-Дек-15, 19:41 
Ну не падала у меня UFS2. ext вот на малинке недавно у друзей-линуксоидов прекрасно умер ВООБЩЕ, fsck не спас. Извини, не имею оснований верить анонимусам со статистикой в "сотни тысяч смертей" на том, что они не используют вообще
Ответить | Правка | Наверх | Cообщить модератору

158. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Нимано (?), 16-Дек-15, 20:20 

> верить анонимусам со статистикой в "сотни тысяч смертей" на том, что

Берём какой-либо конфиг, затюненый под железку с БП, с async-ами и прочими шахматами, возможно ещё без SU, но с RW и атаймом на "базу", (зато не выносим var/ tmp) и делаем сотню клонов ...

Ответить | Правка | Наверх | Cообщить модератору

160. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от iZEN (ok), 16-Дек-15, 21:39 
>> верить анонимусам со статистикой в "сотни тысяч смертей" на том, что
> Берём какой-либо конфиг, затюненый под железку с БП, с async-ами и прочими
> шахматами, возможно ещё без SU, но с RW и атаймом на
> "базу", (зато не выносим var/ tmp) и делаем сотню клонов ...

Без SU в UFS2 не будет работать упорядочение транзакций записи.


Ответить | Правка | Наверх | Cообщить модератору

163. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 17-Дек-15, 03:25 
> Без SU в UFS2 не будет работать упорядочение транзакций записи.

Кэп, Вы? )
В этом ведь вся фишка – можно будет на форумах писать о том, что УФС регулярно валится на сотне машин, при этом упирая на то, что в ext4 "все работает"!

Тут ведь как:
Очевидно не cрабатывает "sync" мета-данных ФС.
Мне лень в гугол, но SU это вроде как раз хитромудрая атомарная запись мета-данных, именно для того, чтоб при "резком отключении" не остаться у разбитой ФС.
Т.е. атомарность => или запись полная или она вообще отсутствует, а "недосинк" по определению – бажище.

http://www.mckusick.com/softdep/
> Soft updates, an alternative to these approaches, is an implementation mechanism that tracks and
> enforces metadata update dependencies to ensure that the disk image is always kept consistent.

Однако: в мылолистах тишина, в багтрекере тишина, на форумах тишина (почти как на кладбище) и лишь иногда проскакивает "когда можно будет делать снэпшоты при включенном журнале?"

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

А значит, дело скорее всего все-таки в конфиге – или самой бзд или виртуалки (у которой свой кэш и которая кладет большой и толстый болт на все попытки синхронизации).

Ответить | Правка | Наверх | Cообщить модератору

164. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Чаёвник (?), 17-Дек-15, 10:12 
Снапшоты на SU+J делались прекрасно, не было никаких проблем. А зачем отстреливать механизм обеспечивающий целостность ФС и рекомендуемый by default и жаловаться на проблемы, которые сами себе наворотили?
Я так же не понял, как отдельно "тюнить железку под БП". У народа уже блоки питания "из коробки" не работают? Так может с БП проблемы, если их надо тюнить и всё разваливается, может стоит поискать нормальный БП?
Ответить | Правка | Наверх | Cообщить модератору

167. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Аноним (-), 17-Дек-15, 11:25 
А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно можно отлючать питание. В дефолтной конфигурации.

Вопрос: Как протюнить виртуалку под ИБП, если гипервизору не желательно ждать корректных выключений всех гостей?

Ответить | Правка | Наверх | Cообщить модератору

168. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от iZEN (ok), 17-Дек-15, 12:07 
> А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно можно отлючать питание. В дефолтной конфигурации.

...и остаться с консистентной ФС, но с проблемами целостности открытых на запись файлов.

Вообще же, аварийное завершение работы примонтированных ФС в плане штатной операции - не самая подходящая идея для дата-центра. Будет момент, когда прилетит серьёзная ответка горе-администратору за такие вольности.

Ответить | Правка | Наверх | Cообщить модератору

169. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от QuAzI (ok), 17-Дек-15, 12:10 
А разве SU не включено в дефолтной конфигурации? Или Вы по каким-то пионерским мануалам 2002-го года до сих пор вручную всё это размечаете?

SU для UFS2 пришло с FreeBSD 5, а это 2003-ий год.
Ext4 стабильный - 2008-ой год (уже тогда во фре была ZFS).
Btrfs стабильный - вот только недавно. Причём она тоже изначально сделана Ораклом (все ж так любят хаить ZFS за то что от Оракла).
Так для вас проблема, что если ГАДИТЬ РУКАМИ ВО ВСЁ что для вас делали последние 12 лет, то странно затвиканная ФС, запущенная на другой странно затвиканной ФС, запущенной на непонятном винте, может вести себя странно если выстрелить в БП?

Если вам не нужно сохранять стейт гостей, то проще поднимать снапшоты RO (кстати, Docker разве делает не так же?), а всю текучку сливать по NFS или другим удобным методом, ИМХО. И ваши волосы будут мягкими и шелковистыми.

Ответить | Правка | Наверх | Cообщить модератору

172. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Анонимemail (1), 17-Дек-15, 13:40 
У вас кроме локалхоста где-нибудь есть btrfs? Например на БД где хранят бабки людей есть ли btrfs или хотя бы всеми любимый ext4?

Вот пример что ntfs/zfs/jfs2(AIX) есть на таких сервера почти везде

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

187. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Аноним (-), 17-Дек-15, 17:18 
> У вас кроме локалхоста где-нибудь есть btrfs? Например на БД где хранят
> бабки людей есть ли btrfs или хотя бы всеми любимый ext4?
> Вот пример что ntfs/zfs/jfs2(AIX) есть на таких сервера почти везде

- бтр, зфс, ехт4 - дев и прод ВМ. О бабках - 5 видеопорталов, биллинг, хранение видео.

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

186. "Оценка методов противостояния потере данных в ФС при крахе с..."  +1 +/
Сообщение от Аноним (-), 17-Дек-15, 17:14 
- Сохранять гостей - не надо. Надо, чтобы они не разваливались из-за выключения и бзды внутри.
- Я не говорю о том, включен SU или нет по дефолту. Я о том, что с него нет толку.
- Из странно затвиканых ФС - ЗФС, работает хорошо. На линуксе, в продакшне, со снэпшотами.
- NFS? - НЕТ! Есть куча других ФС для тех же юзкейсов, но мне не надо никого сливать, у меня и так хранилище в цефе.
Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

189. "Оценка методов противостояния потере данных в ФС при крахе с..."  –2 +/
Сообщение от Аноним (-), 17-Дек-15, 17:24 
>Я не говорю о том, включен SU или нет по дефолту. Я о том, что с него нет толку.

Т.е. даже не включен?
Или просто классическое "у всех работает, у меня не работает – значит на самом деле ни у кого не работает и вообще, все ... а я д'Артаньян!!"

рукалицо.жпг

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

204. "Оценка методов противостояния потере данных в ФС при крахе с..."  +1 +/
Сообщение от Аноним (-), 18-Дек-15, 19:09 
Вообще-то, уфс падала не только у меня, и с включеным  SU, так кто здесь д"Артаньян? Перечитай мои комменты ещё раз, там писалось о том, что в остальные фс таких проблем не имеют.
Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

211. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 18-Дек-15, 22:38 
> Вообще-то, уфс падала не только у меня, и с включеным  SU,

Багрепорт? Конфиги ВМки и БЗДы?

> так кто здесь д"Артаньян?

Очевидно тот, кто плюсует сам себя? )

> Перечитай мои комменты ещё раз, там писалось
> о том, что в остальные фс таких проблем не имеют.

Багрепорты или хотя бы пара конфигов есть? Даже не срaча, а интереса ради  ...

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

180. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 17-Дек-15, 15:27 
> А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно
> можно отлючать питание. В дефолтной конфигурации.

УФС тоже. Правда, проблему на уровне недописанных файлов никто не отменял, но на уровне ФС все будет зашибись.

> Вопрос: Как протюнить виртуалку под ИБП

Да никак, дефолт установка уже сама по себе идет с SU+J.
Лучше же конечно сделать корень ридонли, вынести /var /tmp /usr/local и т.д на отдельный раздел ... но не критично все это на самом деле.

Ответить | Правка | Наверх | Cообщить модератору

205. "Оценка методов противостояния потере данных в ФС при крахе с..."  +1 +/
Сообщение от Аноним (-), 18-Дек-15, 19:13 
1) Речь шла не о недописанных, а о потери уфс2 до невосстановимого фсцк, состояния.
2) Выноси, не выноси - всё равно получишь вышеописанное. Там речь о виртуалках была, перечитай ещё раз.


Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

210. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 18-Дек-15, 22:35 
> 2) Выноси, не выноси - всё равно получишь вышеописанное. Там речь о
> виртуалках была, перечитай ещё раз.

Я читал:
>> UFS-2 - падала всего лишь сотни раз. На разном железе и виртуалках.
> 1) Речь шла не о недописанных, а о потери уфс2 до невосстановимого

ссылочку на багрепорт и конфиги можно?

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

179. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от Аноним (-), 17-Дек-15, 15:16 
> Снапшоты на SU+J делались прекрасно, не было никаких проблем.

Лайв-дамп для бэкапов.

> А зачем отстреливать
> механизм обеспечивающий целостность ФС и рекомендуемый by default и жаловаться на
> проблемы, которые сами себе наворотили?

Чтобы жаловатья на форумах на неработющую и глючную УФС, вестимо!

> Я так же не понял, как отдельно "тюнить железку под БП".

А фиг его знает, просто отдельные "умельцы" могут такое "натюнить"


Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

140. "Оценка методов противостояния потере данных в ФС при крахе с..."  +2 +/
Сообщение от Аноним (-), 16-Дек-15, 13:24 
> Это у чувака из сабжа ещё при пропадании света флешпамять и всякие
> SSDы не сдыхали, то-то он удивится.
> У каких ФС есть снапшоты и шифрование без костылей а ля "смонтируйте
> поверх ста прокладок"?
> А так же возможность сменить столетний пароль на зашифрованном томе, не потеряв
> успешно все данные на оном?

Вообще, есть уровень устройства хранения данных, а есть уровень собственно ФС. Классические (условно) ФС, вроде FFS/extN/NTFS, работают только на втором, а вот ZFS-Btrfs лезут и на первый. Уже поэтому их сравнивать не совсем корректно, с технической точки зрения. Но корректно с пользовательской...

К чему это я? А, да, шифрование. Его уместнее, возможно, делать на первом уровне, отдельно работающем? Как в softraid опёнковском, например. Правда, последний так до конца и не научили корректно выключаться в случае стекирования... GEOM, вроде, более адекватный в этом плане.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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