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

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

"Доклад Google о файловых системах Linux"	+/–
Сообщение от opennews (??) on 06-Май-11, 23:09
Опубликована (http://google-opensource.blogspot.com/2011/05/linux-file-sys...) видеозапись доклада Майкла Рубина (Michael Rubin), занимающегося системами хранения данных в Google, о причинах миграции с файловой системы Ext2 на Ext4. В докладе показаны результаты исследования производительности EXT2, достоинства и недостатки различных файловых систем, доступных в Linux, причины выбора файловой системы Ext4 для использования на серверах Google. Некоторые тезисы: -  Файловая система Ext2 очень надежна, но имеет проблемы с производительностью при высокой интенсивности ввода/вывода. Из всех дисковых операций 40% было связано с обработкой мета-данных и только 60% с самими данными. При высокой нагрузке удаление 8 Мб файла иногда длилось до 800 секунд, наблюдались проблемы с фрагментацией. Как вариант решения проблемы все мета-данные можно было кэшировать, но это потребовало бы больших затрат оперативной памяти. Еще один недостаток Ext2 - очень долгое выполнение во... URL: http://google-opensource.blogspot.com/2011/05/linux-file-sys... Новость: http://www.opennet.dev/opennews/art.shtml?num=30478
Ответить | Правка | Cообщить модератору

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

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

1. "Доклад Google о файловых системах Linux"	+9 +/–
Сообщение от Phoenix (??) on 06-Май-11, 23:09
Вполне ожидаемые, если не очевидные, результаты...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Доклад Google о файловых системах Linux"	–4 +/–
Сообщение от jameson on 06-Май-11, 23:12
>В Btrfs реализованы очень интересные возможности, но код еще не готов для промышленного применения; Разве не готов? вроде в убунте, в федоре со следующего релиза хотели уже на нее переходить. Когда же готов то будет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Доклад Google о файловых системах Linux"	+8 +/–
	Сообщение от achekalin (ok) on 06-Май-11, 23:24
	Так "промышленное" и "поиграться в системах, на которых тестируют все новое, необкатанное" - это несколько разные вещи. Вот выйдет пару релизов федоры, сотни и тысячи юзеров помучают этоу ФС под разные задачи - может Гугл и посмотрит на нее с большим доверием. Да они небось и сами ее в тесте гоняют уже не первый день, но что-то не понравилось им либо в коде, либо в поведении... Благо, ресурсы и аудит кода сделать, и погонять тесты на железе у них есть.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	159. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от myhand (ok) on 16-Янв-12, 14:36
	> Вот выйдет пару релизов федоры, сотни и тысячи юзеров помучают этоу ФС под разные задачи - может Гугл и посмотрит на нее с большим доверием. Абсолютно уверен в том, что Гуглу наплевать на мнение этих "тысяч юзеров". btrfs давно в настоящих дистрибутивах (Debian, RHEL).  Кому надо - давно использует.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	19. "Доклад Google о файловых системах Linux"	+2 +/–
	Сообщение от Аноним (??) on 07-Май-11, 01:07
	> Когда же готов то будет? Ну так потестируйте на себе, чем больше тех кто тестирует, тем быстрее обезглючат. Но можно просрать данные, уж извините :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	71. "Доклад Google о файловых системах Linux"	+2 +/–
	Сообщение от rshadow (ok) on 07-Май-11, 11:44
	Не все данные одинаково полезны. Можно например на разделе для торрентов потестить.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	94. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Пиу on 07-Май-11, 19:45
	в бинарных дистрах можно и для /usr юзать - какая разница, если всё можно быстро восстановить? с другой стороны есть проблема в кернелпаниках и как они будут воздействовать на систему вцелом.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	99. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 08-Май-11, 07:29
	Юзал я месяц назад этот btrfs в продакшене (нужно было том с компрессией сгородить). основная нагрузка - запись больших файлов в несколько (до 10) потоков. кернелпаники через день. Снес нафиг и поставил xfs - полет нормальный.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	111. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от sam (??) on 08-Май-11, 18:32
	не так давно ставил дебиан тестинг и попробовал btrfs, "показались" тормоза, а потом вспомнил что кое-что забыл сделать при установке, решил поставить заново но уже на ext4 и скорость существенно выросла даже при установке пакетов было заметно, почему не знаю, оставил ext4
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	116. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от anonymous (??) on 08-Май-11, 20:04
	В btrfs до сих пор нет fsck. Если что нибудь произойдет то данным кранты. С учетом того что 99.99999% пользователей никогда не делают бекапов (а остальные 0.00001% тоже не делают но смеются на форумах над последними) использовать эту файловую систему нельзя даже для домашнего компьютера. Просьбы о скорейшем написании fsck ГОДАМИ вежливо отклоняются (ну вот именно сейчас надо решить более важную проблему, вот мы решили я начал писать, продолжаю писать, ой открылось окно патчей в ядро щас выложу патчи и точно-точно-буду-писать-fsck.btrfs). Сначала fsck, только потом переход.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Доклад Google о файловых системах Linux"	+1 +/–
Сообщение от metallic (ok) on 06-Май-11, 23:54
Анадысь рассматривал линуксовые ФС на предмет возможности использования в след. проекте, которые стартует в начале лета, нужно будет хранить 100ТБ. Смотрел-смотрел, пришел к выводу, что екст4 рулит, начал пробовать. Надо ли говорить, что я был в шоке, когда узнал, что мейнстрим ФС до сих пор! В 21 веке! Не может отформатировать раздел размером более 16ТБ. Гуглил, оказалось ФС поддерживает практически безграничные разделы по размерам, но вот не задача, утилиты обслуживания ФС древнючие и не умеют форматировать разделы более 16ТБ. При этом задача по фиксу этой баго-фичи имеет наивысший приоритет, если верить разработчикам, написано это было пару лет назад, не помню уже от какого числа пост был. До сих пор не сделано. Интересно почему? Это так сложно или они в своем коде разобраться не могут? На помойке место у екст4 до тех пор, пока сопровождающие утилиты не будут давать пользоваться всеми возможностями ФС.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vadiml (ok) on 07-Май-11, 00:00
	Если у Вас не будет миллионов мелких файлов, то лучше использовать XFS -- не новая, отлаженная, быстрая, многопоточные чтение-запись (по потоку на каждый экстент), есть дефрагментатор, утилиты восстановления.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от metallic (ok) on 07-Май-11, 00:04
	> Если у Вас не будет миллионов мелких файлов, то лучше использовать XFS > -- не новая, отлаженная, быстрая, многопоточные чтение-запись (по потоку на каждый > экстент), есть дефрагментатор, утилиты восстановления. Не поверите, но у меня как раз таки миллионы мелких файлов :) (по 5-30Мб). А в XFS меня пугает требования к объему памяти для чекдиска, хотя, вроде, можно указать сколько памяти максимум использовать. Вообще да, скорее всего XFS и буду использовать, JFS уже не развивается.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	14. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vadiml (ok) on 07-Май-11, 00:16
	> Не поверите, но у меня как раз таки миллионы мелких файлов :) > (по 5-30Мб). Я под мелкими имел в виду размер в 5-30 кб, XFS не умеет с такими оптимально работать. > А в XFS меня пугает требования к объему памяти для чекдиска, хотя, > вроде, можно указать сколько памяти максимум использовать. Да, это можно задать и лучше заранее посмотреть как :) Хотя за всё время использования у меня проблем с XFS разделами не было, хотя около полугода с ней просидел без UPS, а зимой иногда во всём доме эл-во выбивает. Дефрагментация тоже не пригодилась -- файловая система сама справляется даже на разделах с торрентами (на разделе свободно около 5%): # xfs_db -r -c frag /dev/sdc1 actual 76712, ideal 73345, fragmentation factor 4,39%
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 00:24
	> Да, это можно задать и лучше заранее посмотреть как :) > Хотя за всё время использования у меня проблем с XFS разделами не > было, хотя около полугода с ней просидел без UPS, а зимой > иногда во всём доме эл-во выбивает. > Дефрагментация тоже не пригодилась -- файловая система сама справляется даже на разделах > с торрентами (на разделе свободно около 5%): > # xfs_db -r -c frag /dev/sdc1 > actual 76712, ideal 73345, fragmentation factor 4,39% Ну вы домашний комп и промышленный файловый сервер с iowait >90% почти всегда не путайте :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	27. "Доклад Google о файловых системах Linux"	–2 +/–
	Сообщение от ананим on 07-Май-11, 01:19
	а я вот не путаю - xfs отличный вариант. зыж про мелкие файлы - xfs отлично развилась за последние 2-а года... но кому я это говорю?!!!
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	36. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:42
	> Ну вы домашний комп и промышленный файловый сервер с iowait >90% почти > всегда не путайте :) Ну вот на таком сервере я бы с удовольствием попробовал XFS... :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	63. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от metallic (ok) on 07-Май-11, 10:46
	Я и попробую, скорее всего именно XFS и будет, ибо вариантов особо больше нету.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	47. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Анон on 07-Май-11, 02:23
	> промышленный файловый сервер с iowait >90% почти всегда Это называется начальника жаба душит  дать денег на апгрейд железа, которое можно сказать прогнулось по полной.  С таким "iowait >90% почти всегда" сервер на промышленный как-то не тянет:)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	89. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 16:18
	> С таким "iowait >90% почти всегда" сервер на промышленный как-то не тянет:) С другой стороны, если у вас железо не полностью загружено - вы зря заплатили за него деньги.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	104. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от umbr (ok) on 08-Май-11, 13:44
	Бедность не порок: одни устанавливают железо под пиковые нагрузки, другие мирятся с лагами при пиковых нагрузках.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	142. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 10-Май-11, 12:15
	> Дефрагментация тоже не пригодилась -- файловая система сама справляется даже на разделах > с торрентами (на разделе свободно около 5%): > # xfs_db -r -c frag /dev/sdc1 > actual 76712, ideal 73345, fragmentation factor 4,39% Это вы, батенька, как то скромно живете на XFS # xfs_db -r -c frag /dev/sdd1 actual 297119, ideal 1911, fragmentation factor 99.36% Весь раздел - одна большая файлопомойка под торренты.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	150. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 23-Май-11, 15:23
	> actual 297119, ideal 1911, fragmentation factor 99.36% > Весь раздел - одна большая файлопомойка под торренты. Смотрите, дети, этот сказочный раздолбай качал торенты без преаллокации :)
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	26. "Доклад Google о файловых системах Linux"	–2 +/–
	Сообщение от ананим on 07-Май-11, 01:17
	>Не поверите, но у меня как раз таки миллионы мелких файлов :) (по 5-30Мб). >А в XFS меня пугает требования а меня пугают такие "спецы". зыж скоко дашь за настройку экст4 на 100Тб и больше? :D а, потрындеть! :D понимаю.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	42. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от КО. on 07-Май-11, 01:53
	>>А в XFS меня пугает требования > а меня пугают такие "спецы". Мне вот интересно, а на сервере с 100Тб - неужели с оперативкой какие-то проблемы? Или большому диску большой буфер - не его принцип?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	50. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 02:49
	1. приведите мне сервер с 100Tб винтами и сколько таких винтов нужно. в сторону - реально и сейчас какие винты есть? по 2Тб? 3? 5? так вот, если "вчера" и по 5, то таких нужно 20 штук. но сегодня таких винтов нет. вот пруф на яндексмарките http://market.yandex.ru/guru.xml?CMD=-RR=0,0,0,0-PF=2142356600~GT~sel~6000-VIS=160-CAT_ID=686672-EXC=1-PG=10&hid=91033 только в сборе хранилища. итак, сейчас есть только по 3Тб их нужно - 100/3~=33,(3) - т.е. 34 штуки. сервер говорите? нюню, видать по дешёвке по интернет магазину заказал :D но это всё было в сторону. для размышлений о "качестве" местных тролей. про оперативку - если раздаём по 1Гб/с каналу, то 4Гб ОЗУ хватит и на этот объём с лихвой. зыж могу и про эту цифру привести аналогичные очевидные рассуждения. вот только зачем? :D
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	62. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от mine (ok) on 07-Май-11, 10:04
	Как связаны скорость канала и fsck?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	72. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 11:48
	никак.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	67. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от metallic (ok) on 07-Май-11, 11:24
	> 1. приведите мне сервер с 100Tб винтами и сколько таких винтов нужно. Мы заказали IBM V7000 на 192 дисках по 600ГБ (2.5" 10000rpm) > но это всё было в сторону. для размышлений о "качестве" местных тролей. Ну ты понял, да? > про оперативку - если раздаём по 1Гб/с каналу, то 4Гб ОЗУ хватит > и на этот объём с лихвой. Не понял к чему тут про канал было написано, но он будет 10Гбит, если что
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	74. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от ананим on 07-Май-11, 11:57
	>Мы заказали IBM V7000 на 192 дисках по 600ГБ (2.5" 10000rpm) а фс не выбрали? оригенально. >Ну ты понял, да? с каких пор на ты? >Не понял к чему тут про канал было написано, но он будет 10Гбит, если что ну не понял, так не понял.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	75. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 12:02
	А как выбирать ФС без железа? Будет железо - буду тестить, что шустрее бегает
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	87. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 15:36
	железо как железо. с выбором то его уже определились. фс надо выбирать под задачи. а вот их то вы как раз и не описали, как и то будут ли рэйды, лвм и т.д. и даже такой вопрос - а зачем вам всё нужно иметь именно таким большим куском? его обслуживание - простой всей конструкции. и почему не рассматривали кластерные распределённые фс?
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	91. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 17:23
	Задача - хранилка под не жатое видео (покадрово, каждый кадр по слоям). Файлый - изображения размером 5-30Мб, раздаваться будут по самбе или нфс, не суть. Эти файлики будут собирать в видео несколько человек, т.е. один человек может одновременно работать с парой сотней гигов, раскиданных по всех хранилки. Почему одним разделом? Да так удобнее просто, можно и на 2-3 побить в принципе, только что это даст? По поводу аппаратной реализации. Как уже говорил будет 192 диска по 600гб. Они будут объединены в 6-ые рейды, например по 24 диска, т.е. 8 рейдов. Эти рейды хранилкой будут соединены с логический "агрегат", ОС будет видеть все это дело как один 100ТБ хард. Зачем все 192 диска соединять? Чтобы получить как можно большее кол-во iops на выходе, т.к. этот параметр для нас крайне важен. Про кластерные ФС: зачем она в этой задаче?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	92. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от DarkAGeS (ok) on 07-Май-11, 17:32
	> По поводу аппаратной реализации. Как уже говорил будет 192 диска по 600гб. > Они будут объединены в 6-ые рейды, например по 24 диска, т.е. > 8 рейдов. Эти рейды хранилкой будут соединены с логический "агрегат", ОС > будет видеть все это дело как один 100ТБ хард. Зачем все > 192 диска соединять? Чтобы получить как можно большее кол-во iops на > выходе, т.к. этот параметр для нас крайне важен. ZFS же
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	102. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 13:30
	>ZFS же На чем?
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	107. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от DarkAGeS (ok) on 08-Май-11, 16:26
	>>ZFS же > На чем? http://www.opennet.dev/openforum/vsluhforumID3/76968.html#93
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	96. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Anoni on 07-Май-11, 22:32
	> По поводу аппаратной реализации. Как уже говорил будет 192 диска по 600гб. > Они будут объединены в 6-ые рейды, например по 24 диска, т.е. > 8 рейдов. Эти рейды хранилкой будут соединены с логический "агрегат", ОС > будет видеть все это дело как один 100ТБ хард. Зачем все > 192 диска соединять? Чтобы получить как можно большее кол-во iops на > выходе, т.к. этот параметр для нас крайне важен. 6-й рейд? IOPS? "взаимоисключающие параграфы детектед".
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	103. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 13:30
	> 6-й рейд? IOPS? "взаимоисключающие параграфы детектед". А какой рейд надо?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	117. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от anonymous (??) on 08-Май-11, 20:11
	Только RAID-10, он по записи не пролетает так жутко как все остальные. Ну и контроллеры подороже, с батарейкой, хотя это очевидно.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	118. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 20:21
	Во-первых, у 10-го рейда избыточность 50%, в курсе, да? И стоимость СХД от этого увеличивается почти в два раза. Во-вторых, в моей задаче 98% операция чтения, судя по мониторингу.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	138. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от anonymous (??) on 09-Май-11, 23:46
	Все правильно, не слушай дураков. 640 килобайт всем хватит c избытком. А уж подождать пару недель пока рейд6 поелозит головками чтения записи и повосстанавливает разбросаные по всем дискам куски файлов при сбое - святое дело! Дались им эти несчастные несколько лишних дней. Монтажеры фильма опять же, вместо дурацкой лихорадочной работы за 2-3 дня до окончания срока смогут поехать в лес на шашлыки. Во всем выгода!
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	141. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 10-Май-11, 10:43
	Еще раз: есть бюджет, в который внатяг протолкнули 192 диска, после долгих дебатов, собраний и т.д. Чтобы сделать 10-ый рейд - железа надо в два раза больше (дисков и полок). Про пару недель не понял, это речь идет о ребилде? Так ребилд 600Гб диска 10000rpm в шестом рейде идет пару часов, боевые серваки, которые сейчас есть (на 24шт 1ТБ 7200rpm дисках) ребилдятся за сутки-полтора, при этом работать-то можно, тормозит, но работает. Откуда дровишки про пару недель - не понятно.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	69. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 11:37
	> Мне вот интересно, а на сервере с 100Тб - неужели с оперативкой > какие-то проблемы? Или большому диску большой буфер - не его принцип? На сервере, который будет подключен к хранилке, будет 8Гб памяти. xfs_check с дефолтными параметрами требует по 2Гб на каждый 1Тб. Т.е. мне надо 200Гб оперативки XD Но там есть опции, которые задают, сколько максимально памяти использовать, но я еще не пробовал.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	78. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от pavlinux (ok) on 07-Май-11, 13:03
	> xfs_check с дефолтными параметрами требует по 2Гб на каждый 1Тб. Где такие волшебные требования?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	85. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 14:55
	В документации к XFS, причем эти требования подтверждены практикой, у меня один серв. уже есть на XFS 20ТБ, там 8Гб памяти, так вот чекдиск в сег файлт падал, пока своп огромный не сделал.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	88. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 16:14
	то что память может закончится при xfs_check - да, указано, но именно про "по 2Гб на каждый 1Тб" - не видел. к тому же xfs действительно быстро развивается - http://xfs.org/index.php/XFS_Status_Updates >XFS status update for January 2010 >... >The biggest changes in xfsprogs 3.1.0 were optimizations in xfs_repair that lead to a much lower memory usage, and optional use of the blkid library for filesystem detection and retrieving storage topology information. и на одной конференции ещё в 2008 утверждалось следующее • Memory usage reductions – allow larger filesystems to be checked in small RAM configs – Introduce more efficient indexing structures – Use extents for indexing free space вот пруф http://xfs.org/index.php/XFS_Status_Updates зыж а как себя ведёт xfs_repair? у него другой апи, а xfs_check - скрипт-оболочка вокруг xfs_db. такую проблему не замечал ни разу - но у нас и памяти всегда хватает. не выставлять же?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	98. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от pavlinux (ok) on 08-Май-11, 01:15
	> В документации к XFS, причем эти требования подтверждены практикой, у меня один > серв. уже есть на XFS 20ТБ, там 8Гб памяти, так вот > чекдиск в сег файлт падал, пока своп огромный не сделал. Какой ей памяти надо RAM или VM ?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	119. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 20:22
	> Какой ей памяти надо RAM или VM ? Свап прокатывает, когда 22Тб раздел проверял.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	64. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 10:51
	> а меня пугают такие "спецы". > зыж > скоко дашь за настройку экст4 на 100Тб и больше? :D > а, потрындеть! :D > понимаю. Когда пытался 22ТБ раздел в екст4 форматнуть - гуглил но решения не нашел. В вики екст4 написано следующее: Currently, Ext3 support 16 TB of maximum file system size and 2 TB of maximum file size. Ext4 adds 48-bit block addressing, so it will have 1 EB1 of maximum file system size and 16 TB of maximum file size .... The code to create file systems bigger than 16 TB is, at the time of writing this article, not in any stable release of e2fsprogs. It will be in future releases. Так вот, если есть какое-то реальное решение - написал бы, а не умничал.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	70. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Lampus (ok) on 07-Май-11, 11:39
	Судя по этому: > Ext4 adds 48-bit block addressing, so it will have 1 EB1 of maximum file system size and 16 TB of maximum file size То есть максимальный размер раздела один _эксабайт_, максимальный размер одного _файла_ 16 Тб. А вообще да, проблема в e2fsprogs такая имеется, видимо тянут для совместимости с ext3, в котором ограничение 16 Тб. Насколько я понял из списка рассылки разрабов, придётся ломать ABI чтобы сделать форматирование разделов более 16 Тб. Вот тут есть древние патчи для поддержки 64-битного режима в ext4dev http://www.bullopensource.org/ext4/ Но это всё голяк, стоит посмотреть в сторону git-версии, там валяются всякие вкусности типа дефрагментатора для ext4.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	76. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 12:40
	Так я об этом и писал, поддержка в ядре большой ФС есть, а вот утилит для создания такой ФС нет.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	73. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от Lampus (ok) on 07-Май-11, 11:53
	Вот патчи e2fsprogs https://github.com/tytso/e2fsprogs-64bit
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	77. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 12:41
	> Вот патчи e2fsprogs https://github.com/tytso/e2fsprogs-64bit "Че-та я очкую, Славик" (С) Хрен знает каким боком этот костыль потом выйдет. Кроме как создать ФС, ее еще потом обслуживать надо, так что я бы не рискнул. Судя по всему все же будет XFS
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	157. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от аывава on 25-Авг-11, 01:34
	>> Если у Вас не будет миллионов мелких файлов, то лучше использовать XFS >> -- не новая, отлаженная, быстрая, многопоточные чтение-запись (по потоку на каждый >> экстент), есть дефрагментатор, утилиты восстановления. > Не поверите, но у меня как раз таки миллионы мелких файлов :) > (по 5-30Мб). > А в XFS меня пугает требования к объему памяти для чекдиска, хотя, > вроде, можно указать сколько памяти максимум использовать. > Вообще да, скорее всего XFS и буду использовать, JFS уже не развивается. у меня был хард с потерей информации (графика главным образом, видео, пдф, немного текста), на нём была установлена ехт журналируемая, после частичного форматирования и записи фс вообще не инитилась. Читал с хард-а форемост-ом (надо сказать отличнийшая штука, проприетарный коммерческий р-студио не лучше фри-форемоста). Так вот графич файлы на предмет их "гожести" я просматривал в наутилус-е в виде эскизов, увеличивая скролом до нужного. Фото исчислялись десятками тысяч, естественно отобразить такое количество за раз в эскизах сложно, тем более если файлы битые. Сначала пробовал порционить по 500 штук, потом до 300шт, потом до 100шт.если 100 еще просматривать можно, то чуть больше кол-во или битости фс сжирает весь рэм и этот жестокий инпут/аутпут. писал тоже на ехт журналируемый. КОнфигурация компа:коре 2 ггц, 3гб озу, видео отдельное 256мб.Если в опреленный момент я с виртуальной консоли не убью наутилус, то выход только ресет. на ехт 4 вообще были пропажи (год назад). С ХФС всё у меня изменилось. никогда не было такого беспредельного поведения, и очень много опций для конфигурирования/монтирования. Использую хфс только не на вар-е и бут-е (домаш. комп, старый рабочий бук), т.к. у неё (фс) слабое место удаление мелких файлов. А вот рекурсивный поиск, запись, многопоточный доступ, равномерный инпут/аутпут, обслуживание (дефраг) реализованы в достаточной мере. Еще бы можно было размер раздела с ней уменьшать :)
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	33. "Доклад Google о файловых системах Linux"	+1 +/–
	Сообщение от AMD Man on 07-Май-11, 01:37
	Под мелкие файлы XFS великолепно тюнится. Гуглится с первого раза... С 2000-х годов почти под сотню серверов работает. Постоянное изучение альтернатив (по совокупным критериям - надёжность,скорость,масштабируемость и т.д.) пока ни к чему не привели...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	37. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:46
	> Под мелкие файлы XFS великолепно тюнится. Гуглится с первого раза... Раньше XFS тормозил если метаданных много, что как раз и есть в случае мелочи. Но в новых ядрах его прилично допилили по этому поводу. Стало вообще хорошо :)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	65. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 10:52
	> Раньше XFS тормозил если метаданных много, что как раз и есть в > случае мелочи. Но в новых ядрах его прилично допилили по этому > поводу. Стало вообще хорошо :) В новых - это каких? Я планирую использовать дебиан 6, там в репах 2.6.32
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	79. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от pavlinux (ok) on 07-Май-11, 13:05
	> там в репах 2.6.32 Фи,... в 2.6.32, ещё delaylog нету.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	81. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 13:11
	> Фи,... в 2.6.32, ещё delaylog нету. Ну придется собрать ядро
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	38. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vadiml (ok) on 07-Май-11, 01:46
	> Под мелкие файлы XFS великолепно тюнится. Гуглится с первого раза... > С 2000-х годов почти под сотню серверов работает. Постоянное изучение альтернатив > (по совокупным критериям - надёжность,скорость,масштабируемость и т.д.) пока ни к чему > не привели... У меня с мелкими файлами только небольшой раздел (200 гиг) под /home, тут меня больше reiserfs устраивает, где-то с 2003-го года так её использую, а для больших разделов уже вылазят её проблемы с маштабируемостью на большие размеры и многопроцессорность
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	43. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:54
	> У меня с мелкими файлами только небольшой раздел (200 гиг) под /home, > тут меня больше reiserfs устраивает, Только почему-то в интернете попадается много случаев когда fsck диск убил. Одна небольшая проблема. Зато какая.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	45. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vadiml (ok) on 07-Май-11, 02:10
	> Только почему-то в интернете попадается много случаев когда fsck диск убил. Одна > небольшая проблема. Зато какая. У меня где-то в 2007 была глючная МВ, глухо вешала систему на голом месте, 2 раза корень с ext3 уходил. Рейзер после каждого зависания тупо отказывал последние изменения и работал дальше, ни разу не было проблем за 8 лет использования.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	51. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 02:58
	всё тоже самое, только фс нужно поменять местами. оракель, 300 гб база, корень с екст3 не проблемма. рэйзер - корень в акуе, база в дауне. (и это не впродакшене, рэйзер вообще для оракеля не точто не сертифицирован, даже не на всех сайтах найдешь упоминания - на девелоперском окружении юзал. после завала брал копию с продакшена. потом надоело)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	105. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vadiml (ok) on 08-Май-11, 14:55
	> всё тоже самое, только фс нужно поменять местами. > оракель, 300 гб база, корень с екст3 не проблемма. > рэйзер - корень в акуе, база в дауне. (и это не впродакшене, > рэйзер вообще для оракеля не точто не сертифицирован, даже не на > всех сайтах найдешь упоминания - на девелоперском окружении юзал. после завала > брал копию с продакшена. потом надоело) reiserfs для баз данных противопоказан -- постоянный sync базы убивает его преимущества, а откаты журнала при ошибках убъют базу. Я для оракла использовал только xfs с выносом журнала на отдельный диск ещё с 2005-го года А вот для /home с миллионами мелких файлов на однопроцессорных системах -- это одна из лучших fs (хотя в 33-м ядре работу с несколькими cpu и улучшили, но если на неё копировать файлы файлы в несколько гиг, то всё равно впадает в ступор).
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	11. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Anonymousapiens (ok) on 07-Май-11, 00:07
	100Тб чего, если не секрет?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от metallic (ok) on 07-Май-11, 00:11
	> 100Тб чего, если не секрет? В каком смысле чего? Содержимое? Не жатое видео по слоям и кадрам
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Anonymousapiens (ok) on 07-Май-11, 00:16
	Спасибо, ясно.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	28. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 01:21
	это он выше про мелкие файлы говорил. :D
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	30. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:32
	> В каком смысле чего? Содержимое? Не жатое видео по слоям и кадрам XFS с ним неплохо справится. Особенно в свежих ядрах, где работу с метаданными ускорили. А если это несколько дисков, было бы очень умно размазать на них XFS с правильными параметрами. Поскольку она пишет данные параллельно, скорость может взлететь пропорционально числу дисков в массиве.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	31. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ананим on 07-Май-11, 01:35
	yt поверишь, но "правильные" параметры она подбирает сейчас сама. проверял. я конечно не супер-пупер, но автомат справился лучше. короче, xfs - очень хорошая фс. уже и для обычного применения.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	20. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:09
	> Анадысь рассматривал линуксовые ФС на предмет возможности использования в след. проекте, > которые стартует в начале лета, нужно будет хранить 100ТБ. XFS по вашему видео плачет. Разложить на страйп с грамотными параметрами. Взлетит просто. Особенно на более-менее крупных файлах. SGI делало станции видеомонтажа, сами понимаете что там за файлы.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	66. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 10:54
	> XFS по вашему видео плачет. Разложить на страйп с грамотными параметрами. Взлетит > просто. Особенно на более-менее крупных файлах. SGI делало станции видеомонтажа, сами > понимаете что там за файлы. У меня аппаратный рейд будет, зачем еще какой страйп?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	110. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от fi (ok) on 08-Май-11, 16:56
	>> SGI делало станции видеомонтажа, сами понимаете что там за файлы. >У меня аппаратный рейд будет, зачем еще какой страйп? Вот это интересный вопрос, далеко не каждый hw-рейд может потягаться с полноценным sw-рейдом. Уже не раз натыкался на статьи, где это обсуждалось. Как я понял, основная проблема, что зачастую в рейдах используется старое слабое железо, а переделать под новое - дорого стоит. И годами прошивки не исправляются. А ведь  hw-рейд - это просто еще один маленький комп :) так что советую, пока будете настраивать, прогнать тесты, даже на вашем суперрейде.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	123. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 22:48
	Попробуем, но V7000 покупаем как раз потому, что DS3512 не умеет рейды в логические диски объединять, не хотелось это делать на уровне ОС. V7000 - железка новая, сравнительно недавно продаваться начала, так что должно быть все нормально там с контроллерами, посмотрим.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

6. "Доклад Google о файловых системах Linux"	+/–
Сообщение от vadiml (ok) on 06-Май-11, 23:56
> XFS - отличная производительность, но большая усложнённость реализации; Я большинство разделов перевёл на XFS пару лет назад и до сих пор не жалею, а по сложности реализации btrfs и zfs её сильно обойдут из-за кучи дополнительных фич. только корень оставил на Ext3 -- что-то не хочется быть тестировщиком Ext4. На работе на части серверов аналогичная разбивка. Главное чтобы система была 64-битной.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:29
	> Я большинство разделов перевёл на XFS пару лет назад и до сих > пор не жалею, XFS хороша для больших файлов, типа торентов всяких, видео, даже нежатого и прочая. > а по сложности реализации btrfs и zfs её сильно обойдут из-за кучи дополнительных фич. XFS журналит только метаданные. Упомянутые журналят все, не теряя в скорости. Да еще и снапшоты попутно могут делать. Некоторая разница. > только корень оставил на Ext3 -- что-то не хочется быть тестировщиком Ext4. EXT4 объявили стабильной чуть ли не 10 версий ядер назад. У многих она уже по умолчанию в дистрибутивах. Теперь она и у гугла. У вас настолько крутой энтерпрайз что гугл ему в подметки не годится? Или вы видите массовые вопли пострадавших от EXT4? > На работе на части серверов аналогичная разбивка. > Главное чтобы система была 64-битной. Тем не менее, на кучу небольших файлов EXT4 получше будет.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	32. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от ананим on 07-Май-11, 01:36
	>XFS хороша для больших файлов, типа торентов всяких, сразу ясно - человек не понимает о чём говорит.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	39. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:47
	> сразу ясно - человек не понимает о чём говорит. Слишком толсто. Конкретнее, Склифосовский!
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	52. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от ананим on 07-Май-11, 03:11
	конкретнее? торент юзает мелкие фрагменты файлов. (и пишит ими же в фс) преалокация большого куска таки есть уже даже в ufs. но в рамках которого торент и гоняет эту мелочёвку - то качает, то раздаёт рандомно. естесно кэш ос об этом запросе на следующий мелкий кусок очередного клиента не догадывается и юзает свой алгоритм. есть ещё вопросы? http://ru.wikipedia.org/wiki/BitTorrent
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	55. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от ананим on 07-Май-11, 03:36
	зыж и тем не менее он в одном прав - xfs отличный выбор и для торрентов. почему? потому что эта современная много-потоковая (подчеркну!) фс отлично уже работает и с мелкими файлами. не зря её красная шапка дорабатывала и теперь отлично поддерживает в своём рхел. и в полном стэке применения - от виртуалок, до файлопомоек.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	113. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Drist (ok) on 08-Май-11, 19:44
	А как там на счет файлов, забитых полностью нулями? Приходилось читать про эту особенность фс при сбоях системы. Опасность сия сильно преувеличена или как?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	151. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 23-Май-11, 16:36
	> А как там на счет файлов, забитых полностью нулями? Дочинивалось в .28 ядре, чтоли. Более свежие этим особенно не страдают вроде.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

8. "Доклад Google о файловых системах Linux"	–1 +/–
Сообщение от Аноним (??) on 07-Май-11, 00:01
>ZFS - отличная производительность, высокая надежность и богатые возможности с одной стороны, вам ехать? >но с другой стороны несовместимая с GPL лицензия на код; или шашечки? На пост о том как отформатировать и юзать 100TB - это тоже ответ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 07-Май-11, 00:02
	Это мне про ZFS? А на чем ее крутить? На бзде? Спасибо - идите мимо. Особенно в свете последних событий с ораклом и ко.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	16. "Доклад Google о файловых системах Linux"	–3 +/–
	Сообщение от Аноним (??) on 07-Май-11, 00:36
	Лол. Ну юзайте 16гиговый ext4, профессианал :)))
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	21. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 01:11
	> Лол. Ну юзайте 16гиговый ext4, профессианал :))) Во первых, 16Тб != 16Гб, дилетант. Во вторых, для 100Гб файлов есть хоть тот же XFS, который на них рулит и педалит.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	46. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 02:17
	>> Лол. Ну юзайте 16гиговый ext4, профессианал :))) > Во первых, 16Тб != 16Гб, дилетант. Во вторых, для 100Гб файлов есть > хоть тот же XFS, который на них рулит и педалит. У вас диск на 16 Терабит? PS. С формулой 16Тб != 16 Гб согласен.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	80. "Доклад Google о файловых системах Linux"	+3 +/–
	Сообщение от pavlinux (ok) on 07-Май-11, 13:10
	> У вас диск на 16 Терабит? 16 Терабод :)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	152. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 23-Май-11, 18:12
	> У вас диск на 16 Терабит? Не вижу никаких проблем набрать составной том на 16Тб. Всего 8 HDD по 2Гб и готово. Мелко плаваете, на хабре юзеры собрали домашнюю файлопомойку на 90Тб.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	93. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от DarkAGeS (ok) on 07-Май-11, 17:40
	> Это мне про ZFS? > А на чем ее крутить? На бзде? Спасибо - идите мимо. Особенно > в свете последних событий с ораклом и ко. курите на дебиане (kfreebsd) ну или на opensolaris/nexenta ps. но лучше на freebsd :)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	112. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 19:23
	> курите на дебиане (kfreebsd) ну или на opensolaris/nexenta > ps. но лучше на freebsd :) Опенсолярис мертв, всякие гибриды как-то не очень доверие вызывают, хотя можно будет попробовать. А во фре ZFS отстает сильно и не достаточно стабильна, я считаю
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	114. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от DarkAGeS (ok) on 08-Май-11, 19:53
	> Опенсолярис мертв, всякие гибриды как-то не очень доверие вызывают, хотя можно будет > попробовать. А во фре ZFS отстает сильно и не достаточно стабильна, > я считаю да не так уж она отстает во фре. v15 сейчас. в следующем релизе будет v28 с дедупликацией и прочим. обновить потом пул и все. можно и сейчас уже юзать v28 на current ветке. а насчет стабильности это вы зря. сколько не пробовал ее убить (дергал питание, винты) не получилось. самое главное, что для ваших задач ZFS это просто идеальный вариант, учитывая все ее плюшки. и так как вы к этому не пришли сами, у меня складывается впечатление, что вы с ней мало знакомы. почитайте статейки и маны, вам понравится, правда) или боитесь freebsd? ;) начните знакомство с debian kfreebsd
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	120. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 08-Май-11, 20:29
	> да не так уж она отстает во фре. v15 сейчас. в следующем > релизе будет v28 с дедупликацией и прочим. обновить потом пул и > все. можно и сейчас уже юзать v28 на current ветке. > а насчет стабильности это вы зря. сколько не пробовал ее убить (дергал > питание, винты) не получилось. > самое главное, что для ваших задач ZFS это просто идеальный вариант, учитывая > все ее плюшки. и так как вы к этому не пришли > сами, у меня складывается впечатление, что вы с ней мало знакомы. > почитайте статейки и маны, вам понравится, правда) или боитесь freebsd? ;) > начните знакомство с debian kfreebsd А зачем ZFS вообще? Что в ней такого? Она хороша для реализации программных СХД и рейдов, а у меня все железное и снапшоты и дедубликация. Какие у нее преимущества перед XFS? Сам я с ZFS знаком на уровне тестовых серверов. FreeBSD не боюсь, наоборт люблю, но в своем круге задач (интернет-шлюз, хостинг и тд), а для файлового сервера лучше линукс полходит, по крайней мере мне так удобнее.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	127. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vle (ok) on 09-Май-11, 00:13
	> А зачем ZFS вообще? Что в ней такого? У ZFS много полезных плюшек, но при таком соотношении disk/ram (100Tb/8Gb) она скорее всего вообще не будет работать. Ну то есть абсолютно. 8Gb памяти на ТАКИЕ объемы говорит о НЕВЕРОЯТНОМ жлобстве и глупости вашего руководства. > Она хороша для реализации > программных СХД и рейдов, а у меня все железное и снапшоты > и дедубликация. Снепшоты и ОСОБЕННО дедупликация требует огромных объемов ОЗУ при массиве в 100Tb. Тем более при мелких файлах, искать описание дедупликации мне лень. Ройте oracle.com. Это не ваш вариант совершенно точно! > Какие у нее преимущества перед XFS? На сайте Oracle расписаны все "фичи". Насколько я понимаю, вам они не нужны. > Сам я с ZFS знаком на уровне тестовых серверов. FreeBSD не боюсь, Если вы не *разработчик* FreeBSD и не готовы им платить, то... Где-то проскакивали весьма-а-а-а-а удручающие бенчмарки FreeBSD+ZFS против Nexenta. Впрочем, я их не воспроизводил.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	130. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от DarkAGeS (ok) on 09-Май-11, 04:33
	> У ZFS много полезных плюшек, но при таком соотношении disk/ram (100Tb/8Gb) > она скорее всего вообще не будет работать. Ну то есть абсолютно. что ей мешает работать при таком соотношении? непонятно > 8Gb памяти на ТАКИЕ объемы > говорит о НЕВЕРОЯТНОМ жлобстве и глупости вашего руководства. не могу не согласиться. > Снепшоты и ОСОБЕННО дедупликация требует огромных объемов ОЗУ > при массиве в 100Tb. Тем более при мелких файлах, искать описание дедупликации дедупликацию пока не пробовал, жду релиза фри с zfsv28. но опять же непонятно про требования к оперативке. 8гб оперативки все таки не так уж мало. zfs можно тюнить под количество оперативки и все такое. вы бы хоть дали ссылки на почитать что ли... > Если вы не *разработчик* FreeBSD и не готовы им платить, то... > Где-то проскакивали весьма-а-а-а-а удручающие бенчмарки FreeBSD+ZFS против Nexenta. тоже почитал бы. надеюсь не фороникс)
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	131. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от DarkAGeS (ok) on 09-Май-11, 04:47
	> А зачем ZFS вообще? Что в ней такого? Она хороша для реализации > программных СХД и рейдов это да > а у меня все железное и снапшоты > и дедубликация. а на чем у вас железные снапшоты и дедубликация?.. > Какие у нее преимущества перед XFS? ну в общем то снапшоты, дедубликация, программные рейды, менеджер томов) > Сам я с ZFS знаком на уровне тестовых серверов. FreeBSD не боюсь, > наоборт люблю, но в своем круге задач (интернет-шлюз, хостинг и тд), > а для файлового сервера лучше линукс полходит, по крайней мере мне > так удобнее. с момента появления zfs лично для меня под файловый сервер лучше подходит именно zfs. тут конечно кому что нравится, это всего лишь инструменты. но есть и объективные причины, уж больно она удобна.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	136. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от metallic (ok) on 09-Май-11, 12:44
	>а на чем у вас железные снапшоты и дедубликация?.. Писал же уже IBM Storwize V7000 >ну в общем то снапшоты, дедубликация, программные рейды, менеджер томов) Из этого мне ничего не надо, я имею ввиду именно какие преимущества в плане базовых функций ФС.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	25. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от Аноним (??) on 07-Май-11, 01:16
	> вам ехать? >>но с другой стороны несовместимая с GPL лицензия на код; > или шашечки? Может быть вы и не догоняете, но сервер состоит не только из файловой системы. К тому же ZFS очень разборчив к нагрузке, наворочен и толком не имеет утилит для восстановления серьезно порушенной ФС.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	109. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iZEN (ok) on 08-Май-11, 16:50
	> К тому же ZFS очень разборчив к нагрузке, наворочен и толком не имеет утилит для восстановления серьезно порушенной ФС. ZFS чуть проще XFS, исходный код лучше откомментирован и оттестирован. Утилиты восстановления для CoW-ФС находятся в самой ФС и отдельно запускать не требуется. Если уж всё сдохло на CoW-ФС, то и восстанавливать, как правило, не имеет смысла.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	97. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Anoni on 07-Май-11, 22:38
	>>ZFS - отличная производительность, высокая надежность и богатые возможности с одной стороны, > вам ехать? >>но с другой стороны несовместимая с GPL лицензия на код; > или шашечки? ZFS требует 1Г памяти на каждый 1Т данных.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	108. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iZEN (ok) on 08-Май-11, 16:47
	> ZFS требует 1Г памяти на каждый 1Т данных. Это откуда такие требования? Быстрому кэшу ARC нужно минимум 1ГБ RAM, а L2ARC имеет динамически изменяемый размер. http://blog.tigranav.ru/2010/11/obyasnenie-arc-i-l2arc/
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

17. "Доклад Google о файловых системах Linux"	+1 +/–
Сообщение от Аноним (??) on 07-Май-11, 00:50
>ReiserFS и JFS не рассматривались в Google как варианты для миграции из-за недостаточной поддержки кодовой базы; Эх Рейзер… Как же мне нравилась эта ФС ( . Я думал, намного будет… Намного лучше будет это всё. Поддерживать кодовую базу ReiserFS больше никто не может ( . Это прискорбно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Доклад Google о файловых системах Linux"	+/–
Сообщение от Анон on 07-Май-11, 02:24
> XFS - отличная производительность, но большая усложнённость реализации; Что они там не осилили в ней?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Доклад Google о файловых системах Linux"	–1 +/–
	Сообщение от ананим on 07-Май-11, 03:18
	выбирали 2 года назад. xfs изменилась с тех пор как и экст с 3 до 4.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

57. "Доклад Google о файловых системах Linux"	–1 +/–
Сообщение от iCat (ok) on 07-Май-11, 07:58
"Всякой задаче - свой инструмент"(с)Люди У меня даже на домашней машинке несколько разных FS. / - reiserfs /boot - ext3 /home - reiserfs /local_multimedia - XFS /docs - reiserfs /net_storage - zfs Я так думаю, что такая картина у многих, кто ищет инструмент для задачи, а не проповедует религию...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Доклад Google о файловых системах Linux"	+2 +/–
	Сообщение от djo (??) on 07-Май-11, 08:57
	А теперь попробуем со всем этим взлететь))!
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	59. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iCat (ok) on 07-Май-11, 09:04
	>А теперь попробуем со всем этим взлететь Уже который год... Полёт нормальный! / - reiserfs #множество мелких файлов, необходимо журналирование /boot - ext3 #стабильный состав, простая FS /home - reiserfs #множество мелких файлов, необходимо журналирование /local_multimedia - XFS #довольно крупные файлы, создаются/стираются относительно редко /docs - reiserfs #множество мелких файлов, необходимо журналирование /net_storage - zfs #множество разнообразных файлов, необходимо гибкое управление массивом                    #дисков, подключение по NFS, SMB, FTP. У меня - под управлением                    #NexentaStorCE Разные задачи - разные инструменты.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	82. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от pavlinux (ok) on 07-Май-11, 13:15
	>[оверквотинг удален] > /home - reiserfs #множество мелких файлов, необходимо журналирование > /local_multimedia - XFS #довольно крупные файлы, создаются/стираются относительно редко > /docs - reiserfs #множество мелких файлов, необходимо журналирование > /net_storage - zfs #множество разнообразных файлов, необходимо гибкое управление массивом >             >        #дисков, подключение по NFS, > SMB, FTP. У меня - под управлением >             >        #NexentaStorCE > Разные задачи - разные инструменты. В общем согласен, кроме /boot под ext3, максимум ext2, и монитровать c noauto. Или xfs/reiserfs без журнала и можно выкинуть из ядра поддержку EXT*FS
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	154. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 23-Май-11, 18:39
	> Уже который год... Полёт нормальный! А вот некоторые другие с рейзером почему-то ругаются, когда им fsck превращает том в вермишель.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	156. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iCat (ok) on 24-Май-11, 04:16
	>> Уже который год... Полёт нормальный! > А вот некоторые другие с рейзером почему-то ругаются, когда им fsck превращает > том в вермишель. А вот у меня этот самый fsck отрабатывает нормально... да ещё и "битый" диск смог восстановить...
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	60. "Доклад Google о файловых системах Linux"	–7 +/–
	Сообщение от anonym12qw on 07-Май-11, 09:07
	а я вот я выбираю единственный NTFS, и не разбираюсь в этой кучке непонятных ФС.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	61. "Доклад Google о файловых системах Linux"	+2 +/–
	Сообщение от ананим on 07-Май-11, 09:14
	ну это-то понятно. но тут пишут те, кто разбирается. хотя бы чуть чуть.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	83. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от pavlinux (ok) on 07-Май-11, 13:18
	> а я вот я выбираю единственный NTFS, Надеюсь она у Вас используется как корневая ФС, причём на том же разделе где и Windows 7? И все это работает через FUSE и ntfs-3g?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	84. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iCat (ok) on 07-Май-11, 13:28
	>а я вот я выбираю единственный NTFS А я вот с недавних пор NTFS-у доверяю только саму Windows, а все данные храню на сетевом диске под управлением "Nexenta CE", а там - "православная ZFS". А последней каплей стало падение двух дисков NTFS "на ровном месте": после перезагрузки Windows испортились обе копии MFT.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	122. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от ffirefox on 08-Май-11, 22:36
	> /boot - ext3 А в чем смысл ext3? Почему не выбрать обычную ext2?
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	143. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от анонимоус on 10-Май-11, 15:36
	а в чем смысл отдельного /boot?
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	144. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Andrey Mitrofanov on 10-Май-11, 15:40
	Корень на ФС, которой не умеет бутлоадер.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	145. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от анонимоус on 10-Май-11, 16:43
	> Корень на ФС, которой не умеет бутлоадер. у меня reiserfs,ext2,ext3,ext4,fat запилены в ядро и думаю не только у меня. раньше тоже держал отдельный бут на ext2 но потом понял что с ним гемороя больше ибо очень часто забывал маунтить при обновлении ядра:)
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	146. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Andrey Mitrofanov on 10-Май-11, 17:14
	>>ФС, которой не умеет бутлоадер. Закрузчик, как то: lilo, grub... >у меня reiserfs,ext2,ext3,ext4,fat запилены в ядро >часто забывал маунтить при обновлении ядра:) Читать научитьсь, яколка.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	147. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от анонимоус on 10-Май-11, 18:11
	>>>ФС, которой не умеет бутлоадер. > Закрузчик, как то: lilo, grub... дыг этот самый grub отлично все понимает. просто некоторые использующие отдельный /boot все еще никак не отойдут от разморозки и поэтому не замечают что на дворе уже 2011 год:)
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	128. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vle (ok) on 09-Май-11, 00:20
	Мдэ. Ладно люди /home не жалеют, у большинства там ничего полезного нет. Но систему то жалко, ее ж переставлять придется, конфиги переписывать... /net_storage - понятие сильно растяжимое, чтоб делать какие-то выводы о пригодности/предпочтительности zfs.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	135. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iCat (ok) on 09-Май-11, 12:40
	/net_storage - понятие сильно растяжимое, чтоб делать какие-то выводы о пригодности/предпочтительности zfs. А у меня это "домашний сетевой диск" для всех компов (2 сына, дочь, жена, я). Очень приятна дедупликация, "растяжимость-на-лету" (это когда добавляешь диск), ну и так... по мелочи...
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	139. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от vle (ok) on 10-Май-11, 00:02
	> А у меня это "домашний сетевой диск" для всех компов (2 сына, > дочь, жена, я). Очень приятна дедупликация, "растяжимость-на-лету" (это когда добавляешь > диск), ну и так... по мелочи... OpenSolaris для дома для семьи? Или zfs на линуксе?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	140. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iCat (ok) on 10-Май-11, 03:20
	> OpenSolaris для дома для семьи? Или zfs на линуксе? NexentaStor CE. В общем - да, OpenSolaris в какой-то степени. :) Для дома, для семьи...
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

86. "Доклад Google о файловых системах Linux"	+/–
Сообщение от yantux (??) on 07-Май-11, 15:25
Какой я счастливый человек! Использую ReiserFS  в корне, на внешнем usb HDD изначально стоит NTFS. Всё вроде нормально. Зачем все парятся с этими ФС?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	90. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Аноним (??) on 07-Май-11, 16:28
	У вас с "Гуглом" разные сценарии применения ФС. = К.О.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	101. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iCat (ok) on 08-Май-11, 13:03
	>Какой я счастливый человек!... Тут ведь как оно: можно всё кушать ложкой. И не париться. Да вот только мясо вилкой как-то поудобнее будет. А лапшу - палочками... Впрочем, палочками тоже можно всё кушать... Приятного аппетита!
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

95. "Доклад Google о файловых системах Linux"	+/–
Сообщение от nobody (??) on 07-Май-11, 21:00
>ReiserFS и JFS не рассматривались в Google как варианты для миграции из-за >недостаточной поддержки кодовой базы; ну, ReiserFS понятно. а JFS каким боком? по мне - неплохая фсистема.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	115. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Drist (ok) on 08-Май-11, 20:04
	Есть у jfs проблемы с большими размерами томов. И не факт, что они будут когда-либо решены, если судить по их сайту. Остался только один человек, если не ошибаюсь, который в свободное личное время правит найденные баги. А ведь великолепная классическая фс... Жаль, что не получила развития в сообществе. По-моему, гораздо лучше семейки ехт.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

100. "Доклад Google о файловых системах Linux"	+/–
Сообщение от анон on 08-Май-11, 10:48
ext4 с опциями по умолчанию все еще тормозит при использовании ее на разделе с образами виртуалок?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	121. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от anonymous (??) on 08-Май-11, 20:32
	Образы разные бывают. И файловая система ни причем, тут важно как отрабатываются барьеры и fsync, и в железе жесткого диска, и в контроллере, и в ядре. Скорее всего "все еще тормозит" означает что файловая система использует барьеры, но в железе они реализованы плохо. Есть вариант отключить (-o barrier=0) но тогда не плачьтесь по форумам что данные пропали.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

106. "Доклад Google о файловых системах Linux"	+/–
Сообщение от Аноним (??) on 08-Май-11, 15:28
тема nilfs2 не раскрыта.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	124. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от anonymous (??) on 08-Май-11, 23:27
	А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит когда разделом пользуются долго и свободного места на диске все меньше и меньше. Традиционные ext* более предсказуемые.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	126. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iZEN (ok) on 08-Май-11, 23:54
	> А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные > файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит > когда разделом пользуются долго и свободного места на диске все меньше > и меньше. Не надо обобщать. ZFS не страдает от такой фигни как заполненность диска.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	149. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от nuclight (ok) on 23-Май-11, 14:07
	>> А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные >> файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит >> когда разделом пользуются долго и свободного места на диске все меньше >> и меньше. > Не надо обобщать. ZFS не страдает от такой фигни как заполненность диска. Врать-то зачем? Сходу пример: http://groups.google.com/group/fido7.ru.unix.bsd/tree/browse... и далее по треду, где даже не 95% заполненности.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	155. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от iZEN (ok) on 23-Май-11, 21:25
	>>> А что там раскрывать, первые минуты после свежего форматирования все эти COW-подобные >>> файловые системы (та же btrfs)просто летают. Кирдык и жутчайшая фрагментация приходит >>> когда разделом пользуются долго и свободного места на диске все меньше >>> и меньше. >> Не надо обобщать. ZFS не страдает от такой фигни как заполненность диска. > Врать-то зачем? А я и не вру: % zpool list store NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT store  1,73T  1,70T  30,9G    98%  ONLINE  - % zpool upgrade store This system is currently running ZFS pool version 15. Pool 'store' is already formatted using the current version. % uname -rsm FreeBSD 8.2-STABLE amd64
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

125. "Доклад Google о файловых системах Linux"	+/–
Сообщение от gni on 08-Май-11, 23:46
интересно, а  почему google не инвестирует в разработку reiser4. лично считаю, что деньги бы пошли на пользу. многие бы это приветствовали. фс очень быстра, стабильная. допилили бы и было бы просто круто !!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	132. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от nobody (??) on 09-Май-11, 10:33
	разработчиков мало заинтересованных? проект сам по себе бурно бы развивался, будь большое кол-во приверженцов.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	133. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от nobody (??) on 09-Май-11, 10:35
	> разработчиков мало заинтересованных? > проект сам по себе бурно бы развивался, будь большое кол-во приверженцов. ев*
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	134. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от gni on 09-Май-11, 12:23
	асно :) тогда ворпос, просто сам напрашивающийся, а почему их мало? т.е. нужна реклама, я так понимаю? чтобы мир узнал об этом ?
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	158. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от Я (??) on 16-Янв-12, 12:34
	> асно :) тогда ворпос, просто сам напрашивающийся, а почему их мало? > т.е. нужна реклама, я так понимаю? чтобы мир узнал об этом ? Со стороны Ганса было достаточно антирекламы в LKML, когда он забил болт на reiserfs3 и демонстративно отказался нормально объяснить "почему именно плагины" в reiserfs4.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	137. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от пох on 09-Май-11, 22:41
	> интересно, а  почему google не инвестирует в разработку reiser4. а зачем гуглю инвестировать в сомнительную коммерческую затею человека, который сидит и сидеть будет вечно? Запустите reiserfsck, чем более старую тем лучше - то что вы видите, и есть коммерческая модель этой разработки, пока автор не подсел - вроде бы успешная, этих $25 хватало на хлеб с колбасой - ему, и с маслом - команде (и там на три четверти был бывший наш народ ;) Никакой технологической целесообразности у этой затеи не было и в помине (просто на фоне тогдашней ext3 годилось абсолютно что угодно, лишь бы сделанное руками) > лично считаю, что деньги бы пошли на пользу. Гансу - не пошли бы. Что ему в тюряге с ними делать. рейзерфсу - пошли бы, ну а гуглю-то оно зачем, улучшать мир за свой счет? Гугль взял лучшее из _уже_ допиленного, о чем точно было известно что особых взбрыков можно не ждать, манипуляцией со штатными настройками получил приемлемые для своих условий результаты, и купил ключевого разработчика, чтобы оно и дальше было для него приемлемым, независимо от колебаний генеральной линии. Он почти всегда именно так и делает. Значительно смешнее вопрос почему гугль не инвестирует (в значимых масштабах, в рамках обычной благотворительности - инвестирует) btrfs, раз уж ему оракле не велит пользоваться zfs'ом.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

148. "Доклад Google о файловых системах Linux"	+1 +/–
Сообщение от sic on 16-Май-11, 20:55
Собственно моё IMHO не сколько инное чем у остальных участников флейма. ext4 отлично показала себя при работе с крупными так и с мелкими файлами. Дефрагментации нет, скорость чтение/записи высокая. P.S. это лишь мое скромное/yжасное мнение
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	160. "Доклад Google о файловых системах Linux"	+/–
	Сообщение от AlexAT (ok) on 16-Янв-12, 16:27
	Аналогично. Все стандартные системы - на ext4, ибо мейнстрим. Городить зоопарк ради растопыривания пальцев смысла нет, проще добавить диск в RAID, сменить RAID Level или добавить машину в кластер - в зависимости от потребности.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

161. "Доклад Google о файловых системах Linux"	+/–
Сообщение от Аноним (??) on 17-Янв-12, 01:21
>Файловая система Ext2 очень надежна, но имеет проблемы с производительностью при высокой интенсивности ввода/вывода. ВНЕЗАПНО
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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