форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
Сообщение от opennews (??) on 15-Дек-15, 12:27
Дэн Лу (Dan Luu), опубликовал (http://danluu.com/file-consistency/) заслуживающий внимания разбор ситуации с  фиксацией изменений в различных файловых системах (ext2/3/4, xfs, btrfs). В случае краха системы без применения определённых обходных путей при записи файлов достаточно велика вероятность нарушения целостности или порядка записи данных. Проблема состоит в том, что для разных ФС нужно использовать разные методы обхода проблем, что выливается в достаточно сложные и неочевидные конструкции. <center><a href="http://danluu.com/images/file-consistency/fs_properties.png&... src="https://www.opennet.dev/opennews/pics_base/0_1450169520.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> Единый способ отказоустойчивой записи файлов не выработан, а разработчики часто применяют методы обхода проблем, специфичные для определённых ФС.  Например, некоторые программы надёжно работающие в ext3/ext4 начинают сталкиваться с проблемами после перехода на Btrfs, из-за того, что в программе не учтены особенности поведения Btrfs во время возникновения внештатных ситуаций. В качестве примера приложения, корректно обрабатывающего сбои на разных ФС, отмечается SQLite. Неплохие показатели у PostgreSQL. Одни из худших показателей выявлены в Git и Mercurial. <center><img src="https://www.opennet.dev/opennews/pics_base/0_1450170423.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></center> URL: http://danluu.com/file-consistency/ Новость: http://www.opennet.dev/opennews/art.shtml?num=43524
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Оценка методов противостояния потере данных в ФС при крахе с..."	–5 +/–
Сообщение от Аноним (??) on 15-Дек-15, 12:27
Что-то нет ZFS в табличке, боятся что ли признать, то что у линукса нет ни одной современной ФС?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 12:39
	Ну там еще куча тормозного хлама на FUSE...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	20. "Оценка методов противостояния потере данных в ФС при крахе с..."	–4 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:20
	А вот в вантузе фуза нет! Для тех, кто в танке: ZFS уже давно на ядерном модуле, а фузю потихоньку дропают за ненадобностью.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "Оценка методов противостояния потере данных в ФС при крахе с..."	+6 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 13:09
	А что используется в датацентрах? Неужто BSD? ;)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	64. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 19:19
	CoreOS, SmartOS
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	67. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 19:47
	> а фузю потихоньку дропают за ненадобностью. Откуда дровишки?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	89. "Оценка методов противостояния потере данных в ФС при крахе с..."	–5 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 23:03
	Ему не нужно, значит он свято уверен, что все выпиливают. Это линукс-логика.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	126. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Анонимл on 16-Дек-15, 10:31
	Читай внимательнее, ZFS-FUSE.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	16. "Оценка методов противостояния потере данных в ФС при крахе с..."	–4 +/–
	Сообщение от Меломан1 on 15-Дек-15, 13:46
	Наверно потому что в ZFS нет аналога fsck, т.к. проблемы, которые решает fsck в ZFS решается путем организации пулов с избыточностью.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	24. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:40
	Избыточность сюда никаким боком. man транзакционность.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	44. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от pavlinux (ok) on 15-Дек-15, 16:23
	> Что-то нет ZFS в табличке, боятся что ли признать, то что у линукса нет ни одной современной ФС? На http://top500.org сходи и осознай какое ты говно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	51. "Оценка методов противостояния потере данных в ФС при крахе с..."	–5 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 17:03
	Видимо ты про себя, твои ссылки даже не работают :-) > ping -c 5 top500.org       PING top500.org (46.137.188.112): 56 data bytes --- top500.org ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	56. "Оценка методов противостояния потере данных в ФС при крахе с..."	+6 +/–
	Сообщение от none_first (ok) on 15-Дек-15, 17:30
	с аналогичным результатом пингуется ваша голова ;)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	57. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 17:30
	Все там работает. Чини свой энторнэт, малыш.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	122. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 06:36
	Странно, у меня та же картина. Хотя сам  хост отдает text/html без проблем.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	134. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от антоний on 16-Дек-15, 11:50
	просто хост не отвечает на echo request. кто ж так сайты то проверяет, олухи.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	71. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 20:22
	то-то в последнее время там много ZFS стало появляться, в ущерб остальному..
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	86. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от pavlinux (ok) on 15-Дек-15, 22:53
	> то-то в последнее время там много ZFS стало появляться, в ущерб остальному.. SEARCH RESULTS No results were found in Everything matching your query: ZFS Иль ты про два локалхоста, тогда да, это статистика!
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	107. "Оценка методов противостояния потере данных в ФС при крахе с..."	–6 +/–
	Сообщение от анонанонанонанино on 16-Дек-15, 00:36
	А потом посмотри на 1% линуксов на десктопе
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	108. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от iZEN (ok) on 16-Дек-15, 00:38
	> А потом посмотри на 1% линуксов на десктопе И на Ext4 на Android...
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	127. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Анонимл on 16-Дек-15, 10:34
	на твоём месте я бы посмотрел на процент бздей на десктопе.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	110. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 02:34
	а потом посмотри 99% линукса, на фоне которых 100% "десктопа" - не просматриваются, почти :=)
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

3. "Оценка методов противостояния потере данных в ФС при крахе с..."	–10 +/–
Сообщение от Xenia Joness (ok) on 15-Дек-15, 12:39
Обидно, что в сравнении нет NFTS и HFS. Было бы интересно увидеть их преимущества по сравнении с ext2/3/4, XFS и btrfs
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Оценка методов противостояния потере данных в ФС при крахе с..."	+7 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 12:42
	Вы хотели сказать их недостатки?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от qwerty (??) on 15-Дек-15, 12:49
	Неужели ни одного преимущества нету?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	35. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 15:25
	У FAT есть одно: файлы удаляет быстро. И ещё одно: реализуется тривиально.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	36. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от EuPhobos (ok) on 15-Дек-15, 15:40
	> У FAT есть одно: файлы удаляет быстро. Не удаляет, а помечает, что в дальнейшем на эти сектора можно сверху сделать перезапись..
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	47. "Оценка методов противостояния потере данных в ФС при крахе с..."	–3 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 16:45
	это и есть удаление, балбес. И оно в FAT O(размера файла)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	114. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 04:13
	> У FAT есть одно: файлы удаляет быстро. но только если их мало. в FAT нет никакого индекса директорий кроме линейного списка, поэтому файловые операции на большой иерархии - крайне медленны.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	5. "Оценка методов противостояния потере данных в ФС при крахе с..."	+5 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 12:47
	>> NFTS Простите, что? National Film and Television School? o0
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	14. "Оценка методов противостояния потере данных в ФС при крахе с..."	+9 +/–
	Сообщение от z (??) on 15-Дек-15, 13:43
	Что, Ваганыч, в цирк WiFi завезли?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	209. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Ваганыч on 18-Дек-15, 22:06
	Нет, блин, посетителей [s]психушки[/s] опеннета на стажировку отрядили.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 13:48
	Это линукс детка. Нельзя смотреть на сторонние разработки, особенно на те, до которых тебе далеко и сравниваться с ними.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	21. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:24
	Наверное по этому zfs портировали на линукс. Впрочем, так же как и jfs, xfs.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	28. "Оценка методов противостояния потере данных в ФС при крахе с..."	–5 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:52
	Дык ZFS под линукс не работало, и не работает. Впрочем пользователи btrfs будут гооворить что всё работает, если оценить состояния к использованию в промышленных масштабах, на линуксе это будет равнозначно не работать как zfs так btrfs.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	42. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 16:19
	Повторяй эту мантру чаще. Может полегчает. А так - зфс в продакшне уже давно, в промышленных масштабах.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	90. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 23:06
	>в промышленных масштабах Эк вы вашу пару пентиумов третиьих красиво назвали!
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	116. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 04:19
	> Эк вы вашу пару пентиумов третиьих красиво назвали! Эк вы фэйсбука задвинули. В соседней новости есть фото их третьего пентиума. Тот что с 8 видеокартами.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	115. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 04:17
	> если оценить состояния к использованию в промышленных масштабах Btrfs в фэйсбуке используется. У тебя есть продакшн круче?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	131. "Оценка методов противостояния потере данных в ФС при крахе с..."	–3 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 10:48
	А у Netflix UFS2 и найди того кто больше прокачивает трафика в Северной Америке?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	137. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 13:03
	Ютуб с убунтой. В мире.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	138. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 13:10
	Так вот почему они на слайдшаре выкладывают презентации об оптимизиции производительности линукса.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	161. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Led (ok) on 16-Дек-15, 22:27
	> А у Netflix UFS2 и найди того кто больше прокачивает трафика в > Северной Америке? Шо, прям через UFS2 прокачивает?
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	25. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:41
	> Обидно, что в сравнении нет NFTS и HFS. Было бы интересно увидеть > их преимущества Устаревшие ещё в прошлом веке? Какие нахрен преимущества?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	31. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Нанобот (ok) on 15-Дек-15, 15:06
	а ещё FAT32 для полноты картины
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	48. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 16:47
	> NFTS > преимущества А ты забавный.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	70. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 20:03
	>> NFTS >> преимущества > А ты забавный. Я смотрю, тут все такие чоткие пацаны собрались. А хоть кто-нибудь объяснит, что не так с NTFS, кроме того, что от MS? В плане надежности не хуже той же ext4, а по фичам еще фору даст.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	77. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от angra (ok) on 15-Дек-15, 22:19
	Фрагментация выше, чем у extX. Фича с дополнительными потоками файлов весьма стремная. Есть некоторые проблемы fsck, хотя скорее всего это баг реализации в винде. Другой тип ACL. Но в целом вполне годная ФС, объективно не хуже ext3.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	92. "Оценка методов противостояния потере данных в ФС при крахе с..."	–5 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 23:12
	Спокойно дефрагментирует смонтированный системный раздел. И не надо мне тут детскую манечку, что мол ext'ам дефрагментация не нужна. У вас всё, что у вас же можется только через *опу автогеном, автоматически становится "нинужно". Эдакий линукс-страус с головой в собственной *опе по жизни.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	104. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от angra (ok) on 15-Дек-15, 23:57
	Из A>B(фрагментация ntfs выше, чем в extX) вовсе не следует, что B равно нулю. Ты сам выдумал про ненужность дефрагментации и мастерски разоблачил.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	128. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 10:39
	нинужнатор, о преаллокаторах сначала почитай. Посмотри процент фрагментации реально смонтированных разделов ехт4. И узнай о том, что дефрагментаторы под ехт4 есть.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	95. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 23:26
	> Фрагментация выше, чем у extX. Фича с дополнительными потоками файлов весьма стремная. > Есть некоторые проблемы fsck, хотя скорее всего это баг реализации в > винде. Другой тип ACL. > Но в целом вполне годная ФС, объективно не хуже ext3. Ясно, спасибо.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	118. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 04:21
	> что не так с NTFS, Старая бестолковая ФС, по технологиям на уровне EXT3. Работает медленно, ничего особенного не умеет, журналирование частичное.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	94. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от iZEN (ok) on 15-Дек-15, 23:20
	К широко применяемым NTFS, HFS+ в масс-стораджах хотелось бы увидеть результаты тестирования на стрессоустойчивость "рабочей лошалки" BSD-серверов - UFS2.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	129. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 10:41
	Доводилось использовать UFS2. Лошадка совсем не рабочая. > К широко применяемым NTFS, HFS+ в масс-стораджах Так тонко, что аж толсто.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	146. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Nas_tradamus (ok) on 16-Дек-15, 15:14
	>> Доводилось использовать UFS2. Лошадка совсем не рабочая. Такая не рабочая, что для СУБД с открытым кодом работает быстрее и надежней, чем все остальное. Я в особенности про PostgreSQL. Слайды лень искать, но могу за свой опыт говорить, как человека, работавшего в компаниях с самыми большими PostgreSQL в нашей стране в качестве DBA. И да: быстрее всех с постгресом во фре работает ядро 10.2 . А в Linux - 2.6.32 . Странно, не так ли? )
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	154. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 18:47
	- То, что постгрес на линуксе работает быстрее, чем на бзде - не странно. Много было бенчмарков. - А вот то, что в пределах линукса быстрее всего работают ядра 2.6.32 и 3.13(убунтовское лтс) - это очень интересный факт, который прежде всего обусловлен огромным количеством платформозависимых оптимизаций в коде.Особенно, когда планировщик задач или IO клещится с таковым из СУБД. Ядро за последние несколько лет очень сильно  изменилось в лучшую сторону, особенно по отзывчивости. Например, чтобы впасть в ступор, можно запустить постгрес поверх QCOW2, чего разрабы не предусмотрели явно. Частично лечится с помощью elevator=noop.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	157. "Оценка методов противостояния потере данных в ФС при крахе с..."	–4 +/–
	Сообщение от Nas_tradamus (ok) on 16-Дек-15, 20:16
	> - То, что постгрес на линуксе работает быстрее, чем на бзде - > не странно. Много было бенчмарков. По последним данным и моему субъетивному опыту: на FreeBSD 10.1, 10.2 Постгрес работает лучше, чем на любом Linux. Процентов на 10 быстрее, чем на лучшем для постгреса ядре linux (2.6.32) . По ЦПУ примерно одно и тоже на 10.2 vs. 2.6.32 . Выигрыш идет за счет UFS. Сейчас с linux и postgresql большие проблемы: старые ядра перестают поддерживаться, а постгрес работает в 4 раза медленней на современных ядрах linux. Приглашали людей из известного консалтинга по постгресу в нашей стране: они  только пожали плечами. Придется решать своими силами когда руки дойдут. Жаль что в Linux с DTrace в ядре всё плохо.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	216. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от й on 19-Дек-15, 20:45
	> Выигрыш идет за счет UFS. если можно, чуть деталей: * рейд софтовый или хардовый? * никаких lvm или чего подобного в linux-конфигурации не было?
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	159. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от iZEN (ok) on 16-Дек-15, 20:59
	> Доводилось использовать UFS2. Лошадка совсем не рабочая. Проблемы у вас. У нас работает годами. >> К широко применяемым NTFS, HFS+ в масс-стораджах > Так тонко, что аж толсто. ZyXEL делает SOHO-маршрутизаторы на прошивке NDMS V2. В компонентах USB Storage присутствует поддержка возможности работать именно с NTFS, HFS+ и FAT32 на подсоединяемых флэшках. Про XFS/Ext3/Ext4 - ни сном, не духом. А это, между прочим, БАЗОВЫЙ УРОВЕНЬ, который к масс-стораджам имеет косвенное отношение (ну какой из роутера NAS?! Так, примочки для торрентов). Домашние NAS штатно должны иметь поддержку NTFS и HFS+, поскольку есть спрос на соответствующую функциональность, и он должен быть удовлетворён. Роутеры с базовыми функциями NAS - показатель нужности той или иной функциональности.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	165. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 11:19
	Сколько несвязного бреда, особенно по NTFS и HFS+, особенно когда домашние и промышленные насы на ехт4 работают. > Проблемы у вас. У нас работает годами. Проблем с бздой уже давно нет, сразу после ухода бояздэшника. Те же самые машины работают идеально на линуксе.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	171. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 13:33
	Серьёзно ext4? Промышленные??? Скорей домашнее кустарнае, на дешманском и коппечном железе. А промышленные масштабы офис из 5 компьютеров с windows.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	182. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 16:56
	Гнилая у тебя жизнь, но я и не сочувствую. Я так понял, что сотни физмашин и тысячи ВМ - это "Скорей домашнее кустарнае, на дешманском и коппечном железе.", а твои "5 компьютеров с windows." - это промышленные.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	190. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 18:23
	Стрелочник :-) Правда обижает...
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	192. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 20:01
	Ты для начала свой бред перечитай ещё раз, а потом покажи пример своего "продакшна". А насчёт правды - чем больше таких как ты, тем меньше в ИТ-сфере конкуренции.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	193. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 20:05
	Так вот почему у тебя 100500 вопросительных знаков и идиотских смайликов. Стандартное закипание бзды в образе вантузятника.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

7. "Оценка методов противостояния потере данных в ФС при крахе с..."	–3 +/–
Сообщение от Аноним (??) on 15-Дек-15, 12:58
Не совсем ясно о чём рассуждает Дэн Лу если корректная фиксация изменений на любой ФС гарантируется только при использовании различных вызовов fsync*.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 13:06
	Дэн Лу рассуждает о реальной потере данных. Угроза которой появляется сразу же после вызова любой функции записи и сохраняется до возврата из fsync.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	32. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 15:07
	А в чём новость то?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	33. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 15:11
	Вот это что за глупость написана: "Единый способ отказоустойчивой записи файлов не выработан, а разработчики часто применяют методы обхода проблем, специфичные для определённых ФС"?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	40. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Crazy Alex (ok) on 15-Дек-15, 16:03
	Реальная - это когда она в каких-то заметных количествах наблюдается. А этот товарищ посто проповедует.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	19. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 13:51
	Всё тут ясно, рассуждение о том что как плохо нам без ZFS. И то что мы сидим на разработках 70х годов.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
Сообщение от anonymous (??) on 15-Дек-15, 13:07
А где UFS2 с soft updates?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:26
	> А где UFS2 с soft updates? В мусорке. Достала своей падучестью и недосинком. Потом туда же ушла фрибзд, а чуть позже и бояздэшник, её поставивший.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	23. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 14:40
	Обоснуй это Netflix.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	45. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 16:23
	Обоснуй это рамблерам, яндексам, пейсбукам, опачам и прочим гуглам. Ну и ещё вдобавку расскажи о месте бзды в топ500
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	52. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 17:05
	Он уже скидывал выше дохлый top500.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	97. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от . on 15-Дек-15, 23:40
	Ну да - в топ 500 всё сплошь файлопомойки :) опупеннет во всей красе! Павлинукс - а ты в курсе что на кластерах ноды вообще локальных дисков не имеют, и все такие рассуждения о FS для них в приложении к топ 500 ... доставляют :) Впрочем для павлины и нужны для этого ...
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	183. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 16:57
	В топ500 - числодробилки. И ещё, обязательно поищи статистику использования бояздэ там.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	50. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Школьник (ok) on 15-Дек-15, 16:58
	Как она могла тебя достать, если ты ни разу ей не пользовался? :-)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	60. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 17:44
	Тупая ухмылка в смайлике тебе идёт. А на бзду я забил ещё в 2008, ибо уже тогда она начала проигрывать пингвину во всём. Сейчас раз в полгода попадаются ыксперды со своими инсталляциями, которые просто дохнут и тормозят, вот одного недавно ушли.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	98. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от . on 15-Дек-15, 23:42
	> вот одного недавно ушли. Ыффективные фантузянеге ?!
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	130. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 10:44
	Да. Тот бздун ещё и вантузировал на макакоси из-под ворованой вари.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	119. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 04:24
	> Сейчас раз в полгода попадаются ыксперды со своими инсталляциями, которые просто > дохнут и тормозят, вот одного недавно ушли. да их много откуда ушли, пусть идут всей толпой в нетфликс.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	132. "Оценка методов противостояния потере данных в ФС при крахе с..."	–3 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 10:56
	По статистике, если человек знает xBSD, он на порядок лучше знает Linux лучше фанатичного пользователя Linux. В основном 1 к 100 если собеседуешь уг в кадрах кто любит Linux.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	139. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 13:14
	Особенно, если он вантузятнек и этим линуксом не пользуется. Хорошая статистика. Держи нас в курске.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	142. "Оценка методов противостояния потере данных в ФС при крахе с..."	–3 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 14:52
	Бизнесу нужен рабочий инструемент, а не фанатики которые чинят генту после желанных ебилдов, а не выполняют задачи.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	144. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 15:09
	Ты из некрософта? То, что нужно бизнесу, эти самые "фанатики" на убунте или центоси как раз и реализовуют. Расскажи ещё про студенческие поделки Торвальдса, или что та ещё вантузобздуны любят. Такие как ты могут только потреблять, в том числе и блага, созданные "фанатиками".
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	145. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 15:12
	Бизнесу нужен рабочий инструмент, а не фанатики которые чинят боязду после обновления портов, а не выполняют задачи. //fixed
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	147. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 15:19
	> а не фанатики которые чинят боязду после обновления портов О, сразу видно знатока! Зы: Вы забыли проплюсовать себя,  о великий эксперд!
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	166. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 11:20
	а что, setup.exe надо было обновлять?
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	181. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 15:34
	Че, два бота только? Слабовастенько... > а что, setup.exe надо было обновлять? Что сказать-то хотел, ыкспертоид? Зачем "чинить бзду" после обновления портов? Опять: cлышал звон, да не в курсе откуда он? И что вас так бомбит-то от одного упоминания бзд? =)
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	184. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 17:01
	Хотел сказать то, что видел. Все бздуны - вантузятнеги. Кстати, а тебя чего бомбит-то?
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	188. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 17:21
	> Хотел сказать то, что видел. А нам откуда знать, что вы там, в бреду, про порты и бзд видели? Что-то про починку бзд после обновления портов (хоть бы загуглили на тему портов, что ли), потом вообще свой любимый setup.exe приплели. Ну, про бред я уже упоминал, классический "икспертус по бздaм и бздунaм" в своем репертуаре ) > Кстати, а тебя чего бомбит-то? Ну да, это же я в каждой второй новости пишу про бзду и "бздунoв" и какой оне все отстoй! Вам, эксперту, конечно же виднее! )
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	194. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 20:09
	Cлив бздуна. Знакомо. Кроме какашек никаких больше аргументов.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	197. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 22:33
	> Cлив бздуна. Знакомо. Кроме какашек никаких больше аргументов. О великий, во-первых: мухи, тьфу, порты идут отдельно и чтобы "сломать бзду" обновлением портов нужно очень постараться. во-вторых:  у портов есть "срезы", типа "стабильных", а не только "head" в-третьих: внезапно, >  -b  create and keep a backup package of an installed port > By default portmaster creates backup packages of installed ports before >    it runs pkg_delete(1) during an update > Хотя да, это не для джедаев. в-четвертых: опять же, внезапно: pkg backup pkg create -a -o "mybackups" полный бэкап БД и софта! Ух ты! Да да, в случае чего можно будет тупо запустить "pkg add -f". А если перед этим еще и запустить "pkg repo /foo/mybackup" добавив в список реп {url: "file:/foo/mybackup/",              enabled: true } то получится вообще полноценная репа со всеми плюшками1! в-пятых: автоматические сборщики типа poudriere, с атомарным обновлением  репы, поднимающие свой, отдельный джейл для сборки. в-шестых: про отдельную железку для тестов я промолчу, равно как и о read-only для базы, с выносом /usr/local в отдельный раздел и бэкапах на уровне ФС (да да, dump/restore) – не для джедаев это ведь! Но джейл с идетничной конфигурацией, даже тупо на базе основной машинки, только с отдельным /usr/local, религия тоже поднять не позволила? Это каким же надо быть талатнливым ССЗБ и проигнорировав кучу манов и хэндбук, "сломать бзду"? =) Хотя да, это все лирика, зато "чинят боязду после обновления портов" – аргументище иксперта! )
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	198. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 23:15
	Слишком много понтов и бессмысленного онанизма, хотя гугление ты осилил. Просто сегодня нет смысла на 1 машине по 100500 сервисов вращать, вместе с выносом /usr/local. Нужен бэкап - есть директория контейнера или образ вм. Вот только ыксперды, ломающие бзду обновлением портов мне частенько попадались, из бояздэ-фанов кстати.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	199. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 23:43
	> Слишком много понтов и бессмысленного онанизма, хотя гугление ты осилил. Что сказать то хотел, болезный? > Просто сегодня > нет смысла на 1 машине по 100500 сервисов вращать, вместе с > выносом /usr/local. т.е. о том, что имненно в бздах идет в /usr/local, иксперд тоже ни ухом, ни духом? > Вот только ыксперды, ломающие бзду обновлением портов мне частенько попадались, из > бояздэ-фанов кстати. Т.е. аргументов нема, начинаем все сначала? Ну хоть вантуз и путти еще упомянул бы! ЗЫ: отминусовался ты оперативно, а вот проплюсовать себя любимого – забыл! Ай-я-яй!
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	201. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 18-Дек-15, 10:47
	Видать, ыксперд ничего не знает о префиксах сборки ПО. Они могут быть не только в /usr /usr/local, но и в /data/data/com.spartacusrex/files/local, или просто там, где мне удобно в соответствующей ОС этот префикс собрать. Я не минусовал, просто твой бред другим тоже не интересен.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	202. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 18-Дек-15, 13:52
	> Видать, ыкспeрд ничего не знает о префиксах сборки ПО. Они могут быть Не виляй сeдалищем – речь шла о бздaх и портах, а не о сборках от Васяна. https://www.freebsd.org/doc/handbook/dirstructure.html > /usr/local/    Local executables and libraries. Also used as the default destination for the FreeBSD ports framework Но ведь для настоящих джeдая чтение манов – пoнты и oнaнизм! Джeдай лучше денек-другой будет что-то чинить, зато сэкономит 20 минут на чтении! > не только в /usr ... или просто > там, где мне удобно в соответствующей ОС этот префикс собрать. кажется я начинаю догадываться, как обновлением портов таки "поломать бзду". > Я не минусовал, просто твой бред другим тоже не интересен. детский сад, штаны на лямках.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	206. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 18-Дек-15, 19:23
	Таки изучи что такое префикс, и что это можно делать во всех юникс-подобных ОС. Например в тех, где нет /юзр, или просто корень в инитрд. Хотя тeбе это и не снилoсь.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	177. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 14:57
	Рабочий инструмент не ломается как раз, ubunta даже между 14.04.1 до 14.04.2 умеет ловко становиться раком. Не говоря уже про systemd и бинарные логи в CentOS/RHEL. Вы батенько видимо совсем не инженер.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	185. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 17:07
	Ога. Расскажи это тому, кто сотни виртуалок убунты ансиблом между релизами обновлял. И всегда успешно. А ещё я много сисв-инит скриптов на системд переписал. Почему тогда у меня всё работает? Что-то не так делаю. С бздами тоже всё получалось. Может потому, что я не вантузятнег?
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	191. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 18:28
	Угу угу, виртуалок. На реальное железо денег нет? Да и виртуалки обновлять вообще без ansible надо. Это надо быть вообще линуксоидом с низкой квалификацией, что бы так обновлять виртуалки в 21-ом веке. А ты умеешь чинить битый бинарный лог через hex редактор? Похеру, разрешаю даже в windows это сделать.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	195. "Оценка методов противостояния потере данных в ФС при крахе с..."	+3 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 20:14
	> Угу угу, виртуалок. На реальное железо денег нет? Ага, значит облака нематериальны. Ну, это тема для свидетелей иеговы. > Да и виртуалки обновлять > вообще без ansible надо. Тысячи виртуалок, вручную, ага... > Это надо быть вообще линуксоидом с низкой > квалификацией, что бы так обновлять виртуалки в 21-ом веке. Чё? > Похеру, разрешаю даже > в windows это сделать. Спасибо, но такое делай сам.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	196. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 20:16
	> Это надо быть вообще линуксоидом с низкой > квалификацией, что бы так обновлять виртуалки в 21-ом веке. А ты > умеешь чинить битый бинарный лог через hex редактор? Похеру, разрешаю даже > в windows это сделать. Чинить? А не читать? man journalctl
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

13. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
Сообщение от Аноним (??) on 15-Дек-15, 13:39
"не учтены особенности поведения Btrfs" - забавно, что "самая прогрессивная и совершенная фс" требует своего собственного, особого подхода, позволяющего учесть все косяки разработчиков этой "фс".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Оценка методов противостояния потере данных в ФС при крахе с..."	+3 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 13:50
	Лет через 20, будет примерно то что сейчас есть в ZFS.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	27. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от имя on 15-Дек-15, 14:49
	> Лет через 20, будет примерно то что сейчас есть в ZFS. но увидеть это смогут только более другие существа:)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	85. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Вареник on 15-Дек-15, 22:53
	> Лет через 20, будет примерно то что сейчас есть в ZFS. Уже сейчас ближе к народу. Кстати, а где используется Solaris, на который забили с момента поглощения Sun?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	100. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от . on 15-Дек-15, 23:46
	> Уже сейчас ближе к народу. Кстати, а где используется Solaris, на который > забили с момента поглощения Sun? В куче сториджей на который вертятся твои виртуальные дедики. Ни то, ни другое ты не поглядеть, ни пощупать не можешь ... Ну и - ты таки не поверишь!!! - в _линуксе_! Ибо пришли сурьёзные дяденьки из DOD, без чуйства юмора, но с мешком бабла и приказали скрещивать :-\ Зачем то им нада!(С)
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	109. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от . on 16-Дек-15, 00:56
	>> Кстати, а где используется Solaris, Ну да, у нас тут холидэй сизон в разгаре, в обед пива хряпнул :) Ответ был не про Solaris, а про ZFS :) Неее - домой, домой, домой ... :)
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

34. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
Сообщение от коляша (ok) on 15-Дек-15, 15:15
Тоесть разработчики фс дают пользователю опции монтирования которые позволяют ускорить фс в ущерб надежности, а разработчики софта изо всех сил стараются эти опции обойти, вместо того чтобы сказать пользователю "прежде чем менять дефолтные опции монтирования хотя бы мануал по ним почитай дабы поимать чем это чревато дебил". Я считаю что это в корне неправильно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 15-Дек-15, 16:02
	То есть пользователи выбирают опции, которые дают им достаточный уроыень надёжности для большинства ситуаций, а разработчики софта, который требует большего, об этом обычно знают и стараются учитывать. Обычно можно и наоборот сделать - почитать мануал на БД или подобное и синхронизацию отключить к чертям, если в носителе и ФС уверен. Напоминаю - стандартный случай записи в файл на никсах - это "записать обновлённые данные в новый файл, потом переименовать его в старый". И для этого случая никаких проблем нет. А для перезаписи поверх старого - есть, да. Но по факту это в основном касается применений, где надёжность обеспечивается другими способами - бэкапы, сетевые логи и т.п.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	46. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от коляша (ok) on 15-Дек-15, 16:25
	> То есть пользователи выбирают опции, которые дают им достаточный уроыень надёжности для большинства ситуаций А разработчики софта решили насрать на выбор пользователя потому что принимают его за идиота.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	54. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Нимано on 15-Дек-15, 17:08
	>А разработчики софта решили нaсрать на выбор пользователя потому что принимают его за идиота. Угу, мечта разработчика софта: поддерживать пару дюжин комбинаций ФС  и опций. > Проблема состоит в том, что для разных ФС нужно использовать разные методы обхода проблем, что выливается в достаточно сложные и неочевидные конструкции. А если почитать оригинал, то вообще все может стать с ног на голову: The manpage literally refers to rumor. This is the level of documentation we have. If we look back at our example where we had to add an fsync between the write(/dir/log, “2, 3, foo”) and pwrite(/dir/orig, 2, “bar”) to prevent reordering, I don’t think the necessity of the fsync is obvious from the description in the manpage. If you look at the hardware memory ordering “manpage” above, it specifically defines the ordering semantics, and it certainly doesn’t rely on rumor.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	76. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 15-Дек-15, 21:32
	>  I don’t think the necessity of the fsync is obvious from the description in the manpage. Вообще говоря это очевидно.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	162. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Crazy Alex (ok) on 17-Дек-15, 02:45
	А разработчики знают, что их случай - не из этого большинства, и принимают соответствующие меры.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	75. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 21:16
	> Напоминаю - стандартный случай записи в файл на никсах - это "записать > обновлённые данные в новый файл, потом переименовать его в старый". Угу, и это не работает для символических ссылок, для жёстких ссылок, для файлов с ACL и расширенными атрибутами, для больших файлов (не оптимально). Как то не очень хорошо.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	79. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от angra (ok) on 15-Дек-15, 22:24
	> Угу, и это не работает для символических ссылок, для жёстких ссылок Оно и не должно для них работать. Особенно для вторых. > для файлов с ACL и расширенными атрибутами Зависит от софта. Он с тем же успехом может не учитывать и обычные права. > для больших файлов (не оптимально). Зависит от структуры файла. Но там где она позволяет и не применяется этот метод.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	87. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Led (ok) on 15-Дек-15, 22:55
	> Я считаю Ого, вы уже устный счёт проходили?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

38. "Оценка методов противостояния потере данных в ФС при крахе с..."	+3 +/–
Сообщение от Crazy Alex (ok) on 15-Дек-15, 15:56
Почитаешь - жуть. А потом вспоминаешь, что на практике проблем особых нет, и всё это больше похоже на призыв чинить то, что не поломано. Особенно разговор об ошибках диска умиляет - ну да, если диск начал сбоить - выкинь и возьми данные из бэкапа, а то, что на сбойном диске - валидируй на уровне приложения. Стандарный подход. Кстати, хочу заметить, что два отчёта, о которых автор в конце говорит, древние - 2005-го и 2008-го года. не знаю, как насчёт NTFS,  а в линуксе с ФС с тех пор поменялось примерно всё.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
Сообщение от pavlinux (ok) on 15-Дек-15, 16:18
А чо все ФС без барьеров? У XFS хорошая производительность с ними.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 17:07
	Ты чинил хоть раз это дерьмо? Или оно у тебя как top500 работает? LOL
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	74. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 21:10
	> Ты чинил хоть раз это дерьмо? Или оно у тебя как top500 > работает? LOL Мнение неадеквата, обзывающего всё вокруг дерьмом никому не интересно.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	72. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним88 on 15-Дек-15, 20:59
	барьеры и на ext4 не создают излишней нагрузки. в пределах 1-3% просадка производительности.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	73. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 21:09
	При каком профиле нагрузки? Для БД у вас будет не 1-3% TPS просадка от барьеров, а больше.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	208. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 18-Дек-15, 21:49
	"без бареьров" XFS хорош только в SGI-шной версии. без ихних твиков, ванильная версия - что с барьерами, что без - не блещет. исключение - твик на Очень большой буффер, который для эмбеддовки - неприменим а на серваках с декстопами - обходим с тем-же(если не лучше)эффектом.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

58. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
Сообщение от Чаёвник on 15-Дек-15, 17:39
Это у чувака из сабжа ещё при пропадании света флешпамять и всякие SSDы не сдыхали, то-то он удивится. У каких ФС есть снапшоты и шифрование без костылей а ля "смонтируйте поверх ста прокладок"? А так же возможность сменить столетний пароль на зашифрованном томе, не потеряв успешно все данные на оном?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 17:45
	Ответ очевиден -> http://www.oracle.com/technetwork/articles/servers-storage-a... Больше нет ничего, а под линуксом в ближайшие лет 20 ничего ждать не стоит.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

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

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

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

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

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

	158. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Нимано on 16-Дек-15, 20:20
	> верить анонимусам со статистикой в "сотни тысяч смертей" на том, что Берём какой-либо конфиг, затюненый под железку с БП, с async-ами и прочими шахматами, возможно ещё без SU, но с RW и атаймом на "базу", (зато не выносим var/ tmp) и делаем сотню клонов ...
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

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

	163. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 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. Однако: в мылолистах тишина, в багтрекере тишина, на форумах тишина (почти как на кладбище) и лишь иногда проскакивает "когда можно будет делать снэпшоты при включенном журнале?" Хотя вон, есть энтузиасты пилящие бзд под малину (кто-то в рассылке даже упоминал, что "убил" на это дело пару сд-карт и советовал оключить на сдшках журналирование) и уж они должны были "огрести по полной" – фн нет, там тоже тихо. А значит, дело скорее всего все-таки в конфиге – или самой бзд или виртуалки (у которой свой кэш и которая кладет большой и толстый болт на все попытки синхронизации).
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

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

	167. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 11:25
	А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно можно отлючать питание. В дефолтной конфигурации. Вопрос: Как протюнить виртуалку под ИБП, если гипервизору не желательно ждать корректных выключений всех гостей?
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

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

	169. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от QuAzI (ok) on 17-Дек-15, 12:10
	А разве SU не включено в дефолтной конфигурации? Или Вы по каким-то пионерским мануалам 2002-го года до сих пор вручную всё это размечаете? SU для UFS2 пришло с FreeBSD 5, а это 2003-ий год. Ext4 стабильный - 2008-ой год (уже тогда во фре была ZFS). Btrfs стабильный - вот только недавно. Причём она тоже изначально сделана Ораклом (все ж так любят хаить ZFS за то что от Оракла). Так для вас проблема, что если ГАДИТЬ РУКАМИ ВО ВСЁ что для вас делали последние 12 лет, то странно затвиканная ФС, запущенная на другой странно затвиканной ФС, запущенной на непонятном винте, может вести себя странно если выстрелить в БП? Если вам не нужно сохранять стейт гостей, то проще поднимать снапшоты RO (кстати, Docker разве делает не так же?), а всю текучку сливать по NFS или другим удобным методом, ИМХО. И ваши волосы будут мягкими и шелковистыми.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	172. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 13:40
	У вас кроме локалхоста где-нибудь есть btrfs? Например на БД где хранят бабки людей есть ли btrfs или хотя бы всеми любимый ext4? Вот пример что ntfs/zfs/jfs2(AIX) есть на таких сервера почти везде
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

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

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

	189. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 17:24
	>Я не говорю о том, включен SU или нет по дефолту. Я о том, что с него нет толку. Т.е. даже не включен? Или просто классическое "у всех работает, у меня не работает – значит на самом деле ни у кого не работает и вообще, все ... а я д'Артаньян!!" рукалицо.жпг
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

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

	211. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 18-Дек-15, 22:38
	> Вообще-то, уфс падала не только у меня, и с включеным  SU, Багрепорт? Конфиги ВМки и БЗДы? > так кто здесь д"Артаньян? Очевидно тот, кто плюсует сам себя? ) > Перечитай мои комменты ещё раз, там писалось > о том, что в остальные фс таких проблем не имеют. Багрепорты или хотя бы пара конфигов есть? Даже не срaча, а интереса ради  ...
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	180. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 15:27
	> А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно > можно отлючать питание. В дефолтной конфигурации. УФС тоже. Правда, проблему на уровне недописанных файлов никто не отменял, но на уровне ФС все будет зашибись. > Вопрос: Как протюнить виртуалку под ИБП Да никак, дефолт установка уже сама по себе идет с SU+J. Лучше же конечно сделать корень ридонли, вынести /var /tmp /usr/local и т.д на отдельный раздел ... но не критично все это на самом деле.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

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

	210. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 18-Дек-15, 22:35
	> 2) Выноси, не выноси - всё равно получишь вышеописанное. Там речь о > виртуалках была, перечитай ещё раз. Я читал: >> UFS-2 - падала всего лишь сотни раз. На разном железе и виртуалках. > 1) Речь шла не о недописанных, а о потери уфс2 до невосстановимого ссылочку на багрепорт и конфиги можно?
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

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

	140. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 13:24
	> Это у чувака из сабжа ещё при пропадании света флешпамять и всякие > SSDы не сдыхали, то-то он удивится. > У каких ФС есть снапшоты и шифрование без костылей а ля "смонтируйте > поверх ста прокладок"? > А так же возможность сменить столетний пароль на зашифрованном томе, не потеряв > успешно все данные на оном? Вообще, есть уровень устройства хранения данных, а есть уровень собственно ФС. Классические (условно) ФС, вроде FFS/extN/NTFS, работают только на втором, а вот ZFS-Btrfs лезут и на первый. Уже поэтому их сравнивать не совсем корректно, с технической точки зрения. Но корректно с пользовательской... К чему это я? А, да, шифрование. Его уместнее, возможно, делать на первом уровне, отдельно работающем? Как в softraid опёнковском, например. Правда, последний так до конца и не научили корректно выключаться в случае стекирования... GEOM, вроде, более адекватный в этом плане.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

65. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
Сообщение от Аноним (??) on 15-Дек-15, 19:45
Все помешались на этой надежности. Есть дофига задач, в которых потеря данных даже за целый час незначительна. Но при этом ни в одной фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и сейчас. И плевать что это создает излишние тормоза для пользователя и быстро изнашивает ssd.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	68. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Чаёвник on 15-Дек-15, 19:48
	> Все помешались на этой надежности. Есть дофига задач, в которых потеря данных > даже за целый час незначительна. Но при этом ни в одной > фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и > сейчас. И плевать что это создает излишние тормоза для пользователя и > быстро изнашивает ssd. Кеширование в нормальных ФС вполне себе предусмотрено. Если в ваших задачах не критична потеря данных за последний час - хватит качать порнуху. В продакшене за час работы организации вам съедят мозг чайной ложечкой, регулярно помешивая и звонко постукивая об край черепной коробки
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	80. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от angra (ok) on 15-Дек-15, 22:30
	Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и бекапы. Поведай нам жуткие подробности поедания мозга на их примере.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	93. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 23:15
	> Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и > бекапы. Поведай нам жуткие подробности поедания мозга на их примере. За потерю нужных логов на проде поддержку/ИТ казнят лютой казнью. А как бекапы соотносятся с настройкой кеширования - не понятно, если только вы не каждую минуту бекапите систему.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	111. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от angra (ok) on 16-Дек-15, 02:34
	А за потерю логов, которые не понадобились? А это 99% логов. Причем здесь каждую минуту? Может быть и раз в сутки, а может вообще быть непрерывным. Суть в том, что потеря пары часов при создании бекапа вообще никого не волнует, если только ровно в это же время не случился факап и с основным сервером. А ведь бекап может идти и больше чем в одно место и на кратковременное падение одного из них вообще всем плевать.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	141. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 14:05
	> А за потерю логов, которые не понадобились? А это 99% логов. Когда сервер падает, логи автоматически нужны. И именно в этом случае они теряются. Забавно, не находите? > Причем здесь каждую минуту? Может быть и раз в сутки, а может > вообще быть непрерывным. Суть в том, что потеря пары часов при > создании бекапа вообще никого не волнует, если только ровно в это > же время не случился факап и с основным сервером. Если при создании бекапа результат никого не интересует, то неладно что-то в королевстве датском.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	101. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Чаёвник on 15-Дек-15, 23:54
	> Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и > бекапы. Поведай нам жуткие подробности поедания мозга на их примере. Кэширование для бекапов? Серьёзно? У вас клёёёвый прод! И да, если кто-то лезет за бекапом (очевидно потому что текущее файло битое) и не находит бекапа, то кто-то с кешированием "во все ненужные места" пойдёт искать работу =) Логи... ну может быть... но может быть вам такие логи и не нужны? И да, если сервер вдруг раз в час (или сколько вы там себе настроили на кеш) резко проседает под нагрузкой, это тоже как-то ну оооочень странно.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	113. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от angra (ok) on 16-Дек-15, 02:42
	> Кэширование для бекапов? Серьёзно? У вас клёёёвый прод! Ну давай, поделись как надо. > И да, если кто-то лезет за бекапом (очевидно потому что текущее файло > битое) и не находит бекапа, то кто-то с кешированием "во все > ненужные места" пойдёт искать работу =) То есть сразу должен навернуться и бекап и продакшен. мягко говоря не очень частая ситуацияю А если бекап шел сразу на несколько отдельных серверов еще и географически разнесенных? Тоже все сразу навернутся? > Логи... ну может быть... но может быть вам такие логи и не > нужны? Ты не поверишь, но логи не нужны в 99% случаев. Их ведут ради разбора факапов и иногда статистики. На небольшую потерю статистики обычно плевать, а факапы должны случаться достаточно редко. В противном случае проблема совсем не в кешировании. > И да, если сервер вдруг раз в час (или сколько вы там > себе настроили на кеш) резко проседает под нагрузкой, это тоже как-то > ну оооочень странно. Про запись данных раз в час тебе нашептали голоса в голове. Не слушай их, до добра не доведут.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	135. "Оценка методов противостояния потере данных в ФС при крахе с..."	–3 +/–
	Сообщение от Чаёвник on 16-Дек-15, 11:51
	> Ну давай, поделись как надо. Не хочу, когда сами огребёте пару раз - научитесь научитесь, общепринятая практика хранения данных же вам не интересна, всё тлен, всё ненужно > То есть сразу должен навернуться и бекап и продакшен. мягко говоря не очень частая ситуацияю А если бекап шел сразу на несколько отдельных серверов еще и географически разнесенных? Тоже все сразу навернутся? Далеко не все сидят в облаках или имеют инфраструктуру размазанную по принципу "этот сервер будет работать тут, а вон оттого ННАДА чтобы респонсы тормозили посильнее, поэтому перевезём его на северный полюс, заодно сэкономим на охлаждении". Довольно классическая ситуация: вся улица остаётся на несколько часов без света (например из-за пожара у кого-то в другом краю этой улицы). И тут вдруг оказывается, что к вашим костылям с кешированием надо дописывать ещё костыли, которые будут мониторить UPSы и быстренько синкать эти кеши на диск, а так же каждый квартал пачками менять АКБ которые без ваших понтовых костылей вполне бы ещё пару лет поработали, что тоже не самое безболезненное и не самое дешёвое мероприятие. > логи не нужны в 99% случаев Ну так не пишите их, раз они вам не нужны, нафиг вы нам мозг морочите? > Про запись данных раз в час Нашептали в соседнем посте этой же ветки этого же сабжа, дочитывайте всю ветку перед комментированием
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	81. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Ytch (ok) on 15-Дек-15, 22:42
	> В продакшене за час работы организации... Не все сервисы "в продакшене" критически влияют на работоспособность организации. Или у вас там всё что только можно крутится на одном серваке с одним диском/массивом и одной файловой системой на всё? И обычно есть вполне достаточно, например, внутренних сервисов, потеря данных на которых либо вообще легко и автоматически восполнима (а значит не то что за час, за сутки, за неделю можно без особого ущерба все терять), либо совершенно по-другому резервируется/дублируется/зеркалируется/... так что потерялось, да ну и х#@ с ним, постояли, восстановились, засинхронизировались с "выжившими" и поехали дальше... Неприятно? Конечно! Катастрофа? И рядом нет! Так, легкий дискомфорт...
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	121. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Классический анонимуз on 16-Дек-15, 05:42
	Ну и бред. В одной небольшой конторе, где работаю, файловые шары бэкапятся раз в день (несколько терабайт). Попробуй организуй бэкап нескольких терабайт (размазанный по всей РФ) с периодичностью меньше часа (не критична потеря данных за последний час - хватит качать порнуху). И никто не плачет, в SLA написано 1 сутки, бабло дали на данную реализацию. А 1 час - это НАМНОГО дороже.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	136. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Чаёвник on 16-Дек-15, 12:03
	> Ну и бред. В одной небольшой конторе, где работаю, файловые шары бэкапятся > раз в день (несколько терабайт). Попробуй организуй бэкап нескольких терабайт (размазанный > по всей РФ) с периодичностью меньше часа (не критична потеря данных > за последний час - хватит качать порнуху). И никто не плачет, > в SLA написано 1 сутки, бабло дали на данную реализацию. А > 1 час - это НАМНОГО дороже. Это всё ещё про кеширование или уже просто про ненужность работы вашей конторы? Очевидно ваша контора производит "нинужно" и у меня не хватает компетенций, чтобы с вами должно спорить на тему "как грамотно просрать рабочие сутки умноженные на ~180 человек + данные по платежам + бухгалтерия + данные по торговым складам". Возможно Rsync и Ко позволят не тянуть то, что ненужно, чтобы не тягать несколько терабайт (которые у вас фиг менялись), а только дифы. Более того, если интересоваться данной темой, а не только балаболить, можно узнать что и целые ФС можно на лету удалённо реплицировать, что вообще сводит к нулю ваши стоны про несколько терабайт.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	149. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
	Сообщение от Аноним (??) on 16-Дек-15, 15:54
	>   В одной небольшой конторе, где работаю, файловые шары бэкапятся > раз в день (несколько терабайт). Т.е. вы "производите" террабайты данных в сутки или  просто не в силах наладить сам процесс?
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	69. "Оценка методов противостояния потере данных в ФС при крахе с..."	+3 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 19:57
	> Все помешались на этой надежности. Есть дофига задач, в которых потеря данных > даже за целый час незначительна. Но при этом ни в одной > фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и > сейчас. И плевать что это создает излишние тормоза для пользователя и > быстро изнашивает ssd. Вообще-то кеширование есть и даже настраивается. А вам, судя по всему, нужен tmpfs.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	82. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 22:44
	Ну давайте, назовите флаг, который можно установить, чтобы данные записывались на винчестер раз в час..., ну или при заполнении буфера, допустим в 1 Гб. Фс любая из ядра. > Если в ваших задачах не критична потеря данных за последний час - хватит качать порнуху Порнуху уже давно никто не качает. Сейчас качают игры, 4k фильмы. Много программ создает кэш на винчестере, например браузеры, фотошоп. Из серверной области - логи, статистика. Бывает очень большой поток данных. Т.к. вообще сбой системы ооочень редкое явление (у меня электричество вырубают максимум раз в год), а логи вещь второстепенная, то в насиловании жесткого диска не вижу смысла. > А вам, судя по всему, нужен tmpfs. Ага, лить в tmpfs, а из tmpfs на винч. Это ужаснейший костыль. Кэширование (любое, в т.ч. записи) на 100% входит в компетенцию файловой системы.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	91. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 15-Дек-15, 23:11
	> Ну давайте, назовите флаг, который можно установить, чтобы данные записывались на винчестер раз в час..., ну или при заполнении буфера, допустим в 1 Гб. Фс любая из ядра. vm.dirty_expire_centisecs https://lonesysadmin.net/2013/12/22/better-linux-disk-cachin.../ А вообще, гугл в помощь. Было бы желание проблему решить, а не в комментах потрындеть. > Ага, лить в tmpfs, а из tmpfs на винч. Это ужаснейший костыль. Кэширование (любое, в т.ч. записи) на 100% входит в компетенцию файловой системы. _Кеширование_ есть и работает вполне адекватно. А то, что вы описываете - по часу данные в памяти держать - это вы@б, нужный паре неадекватов в мире. Кстати, можете погуглить на тему dm-cache/bcache - может, их можно настроить на использование tmpfs в качестве кеша. Сам я их не использовал, не знаю.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	103. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Чаёвник on 15-Дек-15, 23:56
	> Порнуху уже давно никто не качает. Сейчас качают игры, 4k фильмы. Много > программ создает кэш на винчестере, например браузеры, фотошоп. > Из серверной области - логи, статистика. Бывает очень большой поток данных. Т.к. > вообще сбой системы ооочень редкое явление (у меня электричество вырубают максимум > раз в год), а логи вещь второстепенная, то в насиловании жесткого > диска не вижу смысла. У вас браузер и фотошоп на сервере, зачем вам смысл?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	105. "Оценка методов противостояния потере данных в ФС при крахе с..."	–2 +/–
	Сообщение от Чаёвник on 16-Дек-15, 00:05
	>> Порнуху уже давно никто не качает. Сейчас качают игры, 4k фильмы. Много >> программ создает кэш на винчестере, например браузеры, фотошоп. >> Из серверной области - логи, статистика. Бывает очень большой поток данных. Т.к. >> вообще сбой системы ооочень редкое явление (у меня электричество вырубают максимум >> раз в год), а логи вещь второстепенная, то в насиловании жесткого >> диска не вижу смысла. > У вас браузер и фотошоп на сервере, зачем вам смысл? Ой, я попутал, у вас юзверь на SSD тормозит. Всё равно совершенно не ясно, каким боком линуксовые ФС к фотошопу и главное, как у вас всё это тормозит на SSD. Опять же хочется глянуть на вашу персональную статистику по вылету SSD из-за износа. Я уже молчу про то что фотографам и прочим ребятам РЕАЛЬНО использующим проф. инструмент для обработки избражений будет весьма обидно потерять овердофига работы только потому, что кого-то достало что "все помешались на надёжности". Я вам открою страшную тайну: задача файловой системы - ХРАНИТЬ данные
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	78. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 15-Дек-15, 22:22
	> Но при этом ни в одной фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и сейчас. что за бред несёшь, во многих, если не всех, юниксоподобных ОС запись идёт через кеш который настраивается.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	83. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 15-Дек-15, 22:46
	Пруф в студию
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	112. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 02:37
	технически - он прав. просто в разных ОС и что важнее - в разных ФС(и реализации оных под разные оные и билды оных, что важнее) - оно реализовано Иначе, порой.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	125. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 09:18
	Так есть еще и кеш самой железки - так называемый буфер и writeback кеширование.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

88. "Оценка методов противостояния потере данных в ФС при крахе с..."	+1 +/–
Сообщение от Аноним (??) on 15-Дек-15, 22:59
Дэн Лу фанатик - маразматик. Все ведутся, никто не оценивает положение вещей объективно. Люда - вам не нужна такая безопасность. Ситуаций, когда требуется сохранять всё и сразу можно по пальцам пересчитать. В основном это работа с финансовыми данными. В остальных случаях потеря данных за 5-10 минут раз в год абсолютна не критична. Сбои происходят очень редко, и из-за этого насиловать диск каждой транзакцией бессмысленно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

120. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
Сообщение от Аноним (??) on 16-Дек-15, 04:45
EXT4 + data-journal и забудьте о проблемах. Познавательно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	123. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 08:48
	data-journal снижает производительность иногда на порядок
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	124. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 16-Дек-15, 09:14
	Прежде всего - это надежность!
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	174. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Алконим on 17-Дек-15, 13:53
	Иногда снижает, иногда повышает, фрагментация точно падает.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	200. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 17-Дек-15, 23:59
	За счет того что запись происходит цельным куском по размеру журнала?
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	170. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от iZEN (ok) on 17-Дек-15, 12:11
	> EXT4 + data-journal и забудьте о проблемах. Познавательно. Нет уж. Мы будем как-нибудь ZFS пользовать, а для скорости записи ZIL на SLC SSD вынесем. А вы сидите на своих устаревших технологиях.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	173. "Оценка методов противостояния потере данных в ФС при крахе с..."	+2 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 13:42
	Сам ты устаревший бздун! BTRFS делает во все щели вашу ZFS, и у нас она работает просто великолпено, даже нет таких багов как у бздунов!
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	178. "Оценка методов противостояния потере данных в ФС при крахе с..."	–1 +/–
	Сообщение от Аноним (??) on 17-Дек-15, 14:58
	Когда она упадет, вы будите ныть в оффлайне и без работы.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	203. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 18-Дек-15, 19:02
	Испытываю бтрфс на себе, 2 года - полёт нормальный. После выключений питания поднимается. Я прекрасно понимаю, что рискую результатами 1-3 днями своей работы, но ничего не происходило.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	217. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
	Сообщение от Аноним (??) on 21-Дек-15, 11:58
	> После выключений питания поднимается. Такое даже FAT умеет.
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

133. "Оценка методов противостояния потере данных в ФС при крахе с..."	+/–
Сообщение от borbacucahotmail.com on 16-Дек-15, 11:22
https://ru.wikipedia.org/wiki/%D0%A1%D1%...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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