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

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

"OpenNews: Архитектура файловой системы btrfs"

Сообщение от opennews (??) on 25-Авг-08, 13:39

Вышла статья "Архитектура и реализация btrfs (http://www.filesystems.nm.ru/my/btrfs.pdf)" (PDF, 360Кб). Рассмотрены дисковая структура, базовые алгоритмы, основы администрирования. URL: http://www.filesystems.nm.ru/my/btrfs.pdf Новость: http://www.opennet.dev/opennews/art.shtml?num=17540

Высказать мнение | Ответить | Правка | Cообщить модератору

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

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

1. "Архитектура файловой системы btrfs"

Сообщение от www2 (??) on 25-Авг-08, 13:39

Сложнейшие велосипеды с турбонаддувом. ФС довольно интересная и перспективная, однако о практическом применении речь пока не идёт. Думаю, что простота во многих случаях - гарант надёжности и скорости, фичастость, как правило, ухудшает оба качества.

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

	2. "Архитектура файловой системы btrfs"
	Сообщение от Knuckles (ok) on 25-Авг-08, 13:53
	Простые и надежные уже существуют. Сейчас потребность в фичастых и очень надежных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 25-Авг-08, 13:58
	Вот вот. Даже reiser4, еще каких-то пару лет назад казавшаяся очень перспективной, теперь совершенно заурядна на фоне ZFS и btrfs. Да. Нужны фичастые и надежные. Другие уже просто не поднимутся.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Архитектура файловой системы btrfs"
	Сообщение от User294 (ok) on 25-Авг-08, 15:53
	>Вот вот. Даже reiser4, еще каких-то пару лет назад казавшаяся очень перспективной, >теперь совершенно заурядна на фоне ZFS и btrfs. А что, у них плагины для сжатия\шифрования и прочее вот так штатно задуманы?У рейзера свои сильные стороны, вот только пока все это до ума доведут - можно успеть поседеть :\
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 18:20
	zfs - сжатие да, шифрование здесь http://www.opensolaris.org/os/project/zfs-crypto/ про btrfs - не слышал...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 25-Авг-08, 20:13
	>zfs - сжатие да, шифрование здесь http://www.opensolaris.org/os/project/zfs-crypto/ У рейзера все это - навернутая плагинная архитектура.То есть в принципе модуль сжатия и шифрования можно в идеале выбрать.Вот только есть опасения что я поседеть успею пока Namesys успеет отладить все эти навороты до юзабельного состояния. >про btrfs - не слышал... Где-то сбоку прикрутить ни сжатие ни шифрование не вопрос.Уж шифрование тома сделать не вопрос.Сжатие... ну как минимум есть fuse файловые системы которые по архивам шарятся.Дело в том что у рейзера это не где-то сбоку а штатно.Вот только пока они там все глюки выловят думаю пройдет немеряно времени.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 22:48
	>Вот только есть опасения что я поседеть успею пока Namesys успеет отладить все эти навороты до юзабельного состояния. в том то и дело. от btrfs я жду развития гораздо быстрее. ... может и не рав, но и по структуре она более логична и замечательно на линух ложится (собственно и в pdf-ке об этом) >Где-то сбоку прикрутить ни сжатие ни шифрование не вопрос.Уж шифрование тома сделать не вопрос.Сжатие... да. собственно также, как и в ext. даже одним механизмом можно... в ядре всё что надо есть. плохо то, что до релиза долго. и сейчас развитие как-то приостановилось.. я слежу за сырцами... непонятно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 20:58
	>в том то и дело. от btrfs я жду развития гораздо быстрее. Ну и плюшек типа плагинов для сжатия\шифрования там вроде нет.Впрочем и без них будет неплохо на практике.Кому надо шифрование и другими методами заюзают а емкость современных HDD такова что сжатие вообще нечасто юзают нынче.Даже на том же NTFS. >... может и не рав, но и по структуре она более логична >и замечательно на линух ложится (собственно и в pdf-ке об этом) Вообще хорошая ФС.Учтя что ее только делать начали в 2007 а в 2008 уже как-то ездит - думаю что ее быстро до ума доведут.Оракль после этого явно не выглядит халявщиком который просто спер рхел ;) Одно не нравится - конечно скорость да, но то что там написано про SSD - написано без учета их лимитов по перезаписям.То есть если в пуле будет SSD, убьется он довольно шустро. >да. собственно также, как и в ext. даже одним механизмом можно... в >ядре всё что надо есть. В ext3 так и не сделали сжатие на уровне ФС ;) >плохо то, что до релиза долго. Такие проекты быстро не делаются.Вообще.Даже после того как все вроде бы готово будет еще долгая отладка и обезжучка.Учтя фичность ФС это будет не быстро. Кстати не вижу - там про добавление девайсов есть.А про изъятие чего?Такая же ж**а как с ZFS aka "билет в 1 сторону"?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 26-Авг-08, 22:12
	думаю до "плагинов" ещё очень далеко... но не выполнимо :-) >...Оракль после этого явно не выглядит халявщиком который просто спер рхел ;) ну она теперь на kernel.org, а на сайте oracle только ссылка... >В ext3 так и не сделали сжатие на уровне ФС ;) о чём и хотел сказать :-) думаю как в ext появится, то сразу же и в btrfs будет. (а иногда и наоборот) они вообще довольно близки (пример, конвертация из ext) и думаю, что это классно. >Кстати не вижу - там про добавление девайсов есть.А про изъятие чего?Такая же ж**а как с ZFS aka "билет в 1 сторону"? ну что тут скажешь? могу только заметить, что в btrfs это можно реализовать гораздо проще (и логичней), чем в zfs. ... и вот полностью распределенное блокирование дает широкое поле для идей...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 05-Сен-08, 22:25
	>они вообще довольно близки (пример, конвертация из ext) Конвертация там возможна только благодаря очень специальной структуре btrfs которому пофиг где именно складывать свои структуры.Даже откат на ext3 возможен.Опять же благодаря специфичному подходу btrfs.А близкого ничего нет - EXT3 довольно традиционная система, btrfs - сравнительно новая, на основе бинарных деревьев. >могу только заметить, что в btrfs это можно реализовать гораздо проще (и >логичней), чем в zfs. Ну насчет простоты изъятия тома я не уверен.Как минимум с него придется спихнуть все данные на остальные тома.В принципе это наверное можно.В том же духе как размазывание нагрузки на вновь подключенные тома, только наоборот - сдвинуть все данные с энного тома на остальные тома. >и вот полностью распределенное блокирование дает широкое поле для идей... Да вообще задумана ФС интересно.Ее авторы явно посмотрели на то как сделано в ZFS и в рейзер4 и надергали оттуда лучших идей, по идее должна получиться весьма интересная ФС =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 25-Авг-08, 13:59
	>Простые и надежные уже существуют. Сейчас потребность в фичастых и очень надежных. Ну и какие-же фичи вам так сильно требуются?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Архитектура файловой системы btrfs"
	Сообщение от stiven on 25-Авг-08, 14:25
	Мне кажется раз уж вы задали такой вопрос, то вам как раз эти фичи и не нужны (как и мне собственно). Я воспринимаю ФС, как некий прозрачный механизм хранения файлов и ничего более. Так как очень большие, в большом количестве файлы не храню. Те же ZFS/Reiser мне кажуться чем то отдаленным и чем -то что сложно настроить (нужны какие то комманды вводить, чего тюнить, само по себе не заведётся)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 25-Авг-08, 14:31
	Попробуйте. Это захватывает. Честно :)) Точно также думал, пока сам не посмотрел.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 25-Авг-08, 14:34
	>Попробуйте. Это захватывает. Честно :)) Точно также думал, пока сам не посмотрел. Попробовать-то попробуем. Может и захватит. Однако здоровый консерватизм пока что не позволит мне внедрять её везде и повсюду.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Архитектура файловой системы btrfs"
	Сообщение от Аноним (??) on 25-Авг-08, 15:07
	"настроить" просто само по себе заводится команды вводить? Хмм, да, это проблема. Мысли угадывать оно еще не научилось Тюнить? С таким подходом к вопросу лучше не тюнить :) "по дефолту" надежнее будет
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 25-Авг-08, 20:17
	>Те же ZFS/Reiser мне кажуться чем то отдаленным Reiser 3 делается стандартным mkfs или гуйными утилями.Чего там отдаленного?А Reiser 4 пока сырой глюкастик и юзать его в продакшне и просто на свих данных я бы не стал.Как впрочем и btrfs а также и ZFS (везде кроме солярки, где она уже давно и можно рассчитывать на некоторую обезглюченность).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 25-Авг-08, 14:30
	Почти все, что отличает ZFS от ФС предыдущего поколения. Снапшоты, клоны. Пулы хранения, множественные корни. Сжатие и шифрование данных. COW-журналирование. Производительность на хорошем железе. Я понимаю, что по отдельности почти все это уже так или иначе реализовано -- можно компоновать. Но так УДОБНО, как это сделано в ZFS -- не получится. И поверьте на слово, это много стоит. Я тоже очень скептически высказывался о ZFS -- пока не попробовал. Даже не в деле, а просто в vmware, когда статью про нее делал. И теперь я уверен, что за ней и btrfs -- будущее. С каждым днем это понимают все больше людей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 25-Авг-08, 14:36
	>Я тоже очень скептически высказывался о ZFS -- пока не попробовал. Ну раз Вы её попробовали, к Вашему мнению стоит прислушаться. Надо будет тоже как-нибудь... :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Архитектура файловой системы btrfs"
	Сообщение от Veter (??) on 25-Авг-08, 14:37
	Вы хотите сказать, что с каждым днем об этом все больше людей статьи пишет? :-) Если мерять по количеству статей, то будущее за шоппингом и факингом... А если серьезно, интересны как раз реальные применения на серьезном железе под большой нагрузкой, а как раз этого на виртуалке вы проверить никак не могли. Например, ext3 спокойно держит в одной директории 10 миллионов файлов, а как там у zfs? А на многопроцессорной машине с десятком SAS-дисков в рэйде как оно?.. Так что вы пока рассуждаете о сферической ФС в вакууме.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 25-Авг-08, 14:47
	ээ... за ссылками не ко мне -- я не сантехник. но были тут в каких-то обсуждениях очень интересные примеры по ZFS. если встречу -- обязательно приведу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 25-Авг-08, 14:50
	вот бывает тут некто vitek. он, наверное, лучше расскажет (сорри, если ошибаюсь). одно могу сказать точно -- и 10 миллионов файлов, и десяток SAS'ов -- это как раз то, на что ZFS расчитывалась. В отличие от ext3, кстати.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 17:55
	подтверждаю :-) именно на большом количестве файлов и дисков ZFS и показывает себя во всей красе (конечно и мощность железа должна быть на уровне). >наверное, лучше расскажет да говорить то уже и не о чем. статей по сравнению производительности уже много. найти не трудно. в общем на solaris использовать можно и нужно (а на других платформах в продакшене не использовал). raid-z очень порадовал. (и зачем нужны аппаратные райды? :-)) (железка из 16 FS винтов по 136Gb 15000 rpm. FS - это Fibre Channel, если кто не знает) btrfs тоже очень жду. у неё есть свои плюсы (и не только лицензия - это чтоб войны не разводить). у неё мне нравиться утилиты, которые в стиле unix-way (у zfs собственно тоже не сложные, но несколько непривычный по-началу синтаксис, по моему). + btrfs можно сконвертировать из существующей ext3. и ещё ряд... в общем винтом в 1Tb уже никого не удивишь, а эти fs как раз для таких и выше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Архитектура файловой системы btrfs"
	Сообщение от Аноним (??) on 25-Авг-08, 18:44
	Больше того, zfs заточена под гетерогенные хранилища данных. Так что она отлично себя ведет не только на большом по объему количеству железа, но и большом разнообразии оного.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 19:05
	>Больше того, zfs заточена под гетерогенные хранилища данных. Так что она отлично >себя ведет не только на большом по объему количеству железа, но >и большом разнообразии оного. я так не пробовал, но верю :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Архитектура файловой системы btrfs"
	Сообщение от lomo on 26-Авг-08, 16:25
	Аноним, а скажите plz - в ZFS уже решили проблему, что когда юзер выходит за квоту он уже ничего не может удались из своего home? Ни удаленно (по NFS), ни локально... Однако все прекрасно удаляется из рутовой консоли.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 20:36
	>своего home? Ни удаленно (по NFS), ни локально... Мило.Это что, юзеры будут гарантированно админу мозг выносить при юзании квот? 8-\
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Архитектура файловой системы btrfs"
	Сообщение от lomo on 26-Авг-08, 20:55
	>Мило.Это что, юзеры будут гарантированно админу мозг выносить при юзании квот? 8-\ Пока они и выносят.. Случается не каждый день, конечно, но часто. Забытый дебаг или кривой тест и превед.. Проблема тянется с 2006 года. Свежее обсуждение тут - http://www.opensolaris.org/jive/thread.jspa?messageID=269214... > It's a known problem first mentioned on the ZFS forum in July 2006 > and remains unfixed even in Solaris 10 Update 5. The only workaround > we found is to truncate the file using something > like "cat /dev/null >! file" (for tcsh) since that doesn't trigger > copy-on-write. Unfortunately, it may not be easy to train all users to do that. Но и это мнене всегда помогает, т.к. заполнение файловой системы юзера может быть и кучей мелких файлов и несколькими большими..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 19:04
	сори s/FS/FC/
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Архитектура файловой системы btrfs"
	Сообщение от nal (??) on 25-Авг-08, 15:38
	по данным http://ru.wikipedia.org/wiki/Zettabyte_File_System Ограничения: Максимальный размер файла     16 эксабайт Максимальное количество файлов     2^48 (2 в степени 48) Максимальная длинна имени файла 255 байт Максимальный размер раздела     16 эксабайт
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Архитектура файловой системы btrfs"
	Сообщение от ilja on 25-Авг-08, 18:00
	По поводу поддержки "10 миллионов файлов в одной директории" в ext3, это кто вам сказал? по умолчанию до 32000 файлов, если залезть в ядро то до 65535 файлов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Архитектура файловой системы btrfs"
	Сообщение от angra (ok) on 25-Авг-08, 21:05
	Напиши простой скриптик и проверь. Только слишком большую цифру не ставь, время создания и удаления растет квадратично.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Архитектура файловой системы btrfs"
	Сообщение от Michael Shigorin (ok) on 26-Авг-08, 12:37
	>Напиши простой скриптик и проверь. Только слишком большую цифру не ставь, время >создания и удаления растет квадратично. Хм, сделали ж наконец -O dir_index?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Архитектура файловой системы btrfs"
	Сообщение от Michael Shigorin (ok) on 25-Авг-08, 16:35
	Чтоб данные можно было положить и потом их же забрать. Это обязательно. Крайне желательно, при прочих равных определяет выбор: - выживаемость (мета)данных в нештатных ситуациях - средства восстановления после серьёзного сбоя - скорость укладки/забирания данных   + а теперь под параллельной множественной нагрузкой   + а теперь через год использования ФС, включая случаи забивания >90% - скорость подъёма после конца батарейки в бесперебойнике - минимум жёстких лимитов (вроде предопределённого количества инодов) - поддержка ACL Использую xfs и ext3 -- в зависимости от относительной критичности подпунктов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 25-Авг-08, 16:47
	>Использую xfs и ext3 -- в зависимости от относительной критичности подпунктов. Крайне интересно было бы узнать для каких целей что из них используете и чем руководствуетесь при выборе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Архитектура файловой системы btrfs"
	Сообщение от Michael Shigorin (ok) on 25-Авг-08, 18:04
	>>Использую xfs и ext3 -- в зависимости от относительной критичности подпунктов. >Крайне интересно было бы узнать для каких целей что из них используете >и чем руководствуетесь при выборе. Цели-то одинаковые -- хранение данных :) Выбираю примерно так: - всё, что есть риск потерять -- при возможности или оригинал, или бэкап на ext3   + обычно сопровождается RAID1 - всё, что под тяжёлой нагрузкой, особенно одновременное r/w -- на xfs   + может сопровождаться RAID1/10/5 xfs всем хороша, но в текущих ядрах при монтировании и откате журнала после отвала питания может занулить блоки данных, которые сочтены потенциально попавшими в чужие файлы (утёкшими) -- мера безопасности, которая в сочетании с целыми метаданными ("выглядит как живой") для уникальных данных может быть гибельной.  Вроде с полгода тому собирались ручку приделать, но пока это до серверов доедет... ext3 относительно плохо ведёт себя под нагрузкой, проседает I/O и LA в потолок стреляет.  В смысле "относительно xfs". RAID0 сейчас использую крайне редко, когда-то был довольно частым признаком reiserfs (теперь в таких задачах удобней tmpfs). PS: на всякий -- рекомендованные ссылки по созданию/администрированию RAID: http://www.nber.org/sys-admin/linux-nas-raid.html http://www.pythian.com/blogs/411/aligning-asm-disks-on-linux
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 25-Авг-08, 21:20
	>- всё, что под тяжёлой нагрузкой, особенно одновременное r/w -- на xfs Да, вот этим XFS реально радует.Шустрый.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 22:57
	лучшая из традиционных fs. но не на руте. зы я ext2 юзаю. например, на /boot :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 21:54
	>лучшая из традиционных fs. >но не на руте. Я его использую для того для чего он рулит - хранение больших файлов к которым порой параллельный доступ, преимущественно readonly. На руте EXT3 в общем то неплох (ему бы еще повыше скорость доступа к мелочи да поменьше оверхеда на хранение инодов и было бы замечательно).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 28-Авг-08, 20:23
	>лучшая из традиционных fs. Кстати у него и слабые места есть. Во первых, он журналит только метаданные.Если по части сохранности данных при срубании питания в момент записи есть параноя, лучше полное журналирование как метаданных так и файлов, хоть оно и намного медленее (в разы, ибо данные файла сперва пишутся в журнал, а потом на диск). Во вторых, в интернете есть какие-то наезды про затирание содержимого файлов нулями при внеплановых шатдаунах.Сейчас вроде основную часть проблем отловили, но все-таки. В третьих, на некоторых видах файловых операция XFS не чемпион по скорости и\или по загрузке процессора. В четвертых, layout данной файловой системы пришел с SGIшных систем, которые были отнюдь не х86.Поэтому прямо с нулевого смещения начинаются данные ФС.Это не проблема... пока не хоечется загружаться с этого диска, особенно если он единственный.А когда захочется, оказывается что места для загрузчика\бутсектора (который обитает ВНЕ самой по себе файловой системы) там может и не быть.Ибо с места в карьер начинаются структуры XFS.Прям с нуля.При должном желании это можно обойти.Но потенциально грабли там любизно разложены.К тому же GRUB умеет хитро лажаться при попытках себя записать на XFS.Есть там какой-то недобитый BUG...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "Архитектура файловой системы btrfs"
	Сообщение от Michael Shigorin (ok) on 29-Авг-08, 01:57
	>В четвертых, layout данной файловой системы пришел с SGIшных систем, которые были >отнюдь не х86.Поэтому прямо с нулевого смещения начинаются данные ФС.Это не >проблема... пока не хоечется загружаться с этого диска Диска или раздела?  Перечитайте, а то мне что-то кажется, ерунда какая-то написана.  Хорошо, что мои (и ApplianceWare) корни на xfs её не слышали ;) (целый диск стараюсь под ФС не давать по другой причине -- сложно вспомнить/сообразить, что там данные, не зная этого) >К тому же GRUB умеет хитро лажаться при попытках себя записать на XFS. >Есть там какой-то недобитый BUG... Вот только имя этому BUG -- GRUB.  Что брошенный первый, что сферический второй.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Архитектура файловой системы btrfs"
	Сообщение от Аноним (??) on 25-Авг-08, 18:40
	Ну хотя бы вот такие: http://blogs.sun.com/jonathan_ru/entry/%D0%BE_...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 21:11
	>Ну хотя бы вот такие: http://blogs.sun.com/... Там маркетологи чтоли?В этом блоге много маркетинговой воды - расписано как все будет замечательно и прочая, особенно если связаться с SUN.Коммунисты с их сказками о светлом будущем отдыхают :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 26-Авг-08, 22:28
	это владелец sun блог ведет :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Архитектура файловой системы btrfs"
	Сообщение от ezhik on 25-Авг-08, 22:04
	online fsck, быстрый нетребовательный к памяти fsck. возможность увеличить или уменьшить размера fs добавлением и удалением дисков без выключения машины. Клево, если можно сделать несколько файловых систем на одном пуле дисков (несколько fs на одном разделе). независимость от поставщика.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Архитектура файловой системы btrfs"
	Сообщение от User294 (ok) on 25-Авг-08, 15:50
	>  Сложнейшие велосипеды с турбонаддувом. На фоне какого-нить рейзер 4 пожалуй не предел мечтаний идиота =) А так по моему нормальная ФС в плане соответствия ее сложности ее возможностям. > Думаю, что простота во многих случаях - гарант надёжности и скорости, > фичастость, как правило, ухудшает оба качества. Хм... до некоторой степени согласен, НО вот например... FAT - defective by design.Просто как топор.Но тормозно и с вагоном недостатков.Неактуален. EXT2 - в базовом виде несложен.Только кому он в таком виде нынче нужен?Без журнала то и с тормозным проходом по каталогам.А если с журналингом, хешированием директорий и прочими фичностями - не такой уж он и простой... И так почти везде почему-то - простые фс обычно почему-то медленные и тупорылые :\
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 25-Авг-08, 16:01
	>Хм... до некоторой степени согласен, НО вот например... >FAT - defective by design.Просто как топор.Но тормозно и с вагоном недостатков.Неактуален. Вспомнили старика, он родился во времена дискет, до сегодняшних времён даже и не думал дожить... >EXT2 - в базовом виде несложен.Только кому он в таком виде нынче >нужен?Без журнала то и с тормозным проходом по каталогам.А если с >журналингом, хешированием директорий и прочими фичностями - не такой уж он >и простой... Ну по карйней мере ничего лишнего. В нынешнем виде неплохо работает ext3fs, хотя есть более "неплохо работающие" :) >И так почти везде почему-то - простые фс обычно почему-то медленные и >тупорылые :\ Ну просто - это не значит, что для дурака. Все должно быть изложено так просто, как только возможно, но не проще. (Альберт Эйнштейн) То же самое можно сказать и по отношению к ФС с поправкой на фичастость.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Архитектура файловой системы btrfs"
	Сообщение от Al (??) on 25-Авг-08, 21:09
	>Вспомнили старика, он родился во времена дискет, до сегодняшних времён даже и не думал >дожить... Почему же, xp у меня стоит на fat (даже не представляете, как здорово иногда загрузится из доса и затереть c:\windows :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 25-Авг-08, 21:22
	>Почему же, xp у меня стоит на fat (даже не представляете, как >здорово иногда загрузится из доса и затереть c:\windows :) Пожалуй единственное разумное применение такой дурной конфигурации...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 23:03
	не только. как бы то там ни было, но ввод-вывод у неё быстрее чем у ntfs. т.е. выделение раздела в 1.5-2 раза больше чем ОЗУ и размещение там свопа имеет смысл (кроме безопасности:-))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 20:34
	>как бы то там ни было, но ввод-вывод у неё быстрее чем >у ntfs. Очень зависит от того что, где и как.Сам по себе FAT - тормозной при работе с множеством файлов.Как именно похабный swap-раздел может и сойдет, но в линуксе для этого есть swap-разделы.Так еще быстрее и куда менее черезж*пно.Файловой системы с лишним оверхедом при этом совсем нет и так еще быстрее ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 25-Авг-08, 21:46
	>Вспомнили старика, он родился во времена дискет, до сегодняшних времён даже и >не думал дожить... Ему не дали подохнуть - 32-битным сделали :) >Ну по карйней мере ничего лишнего. Единственное достоинство.Зато сколько там fsck работает в случае любого незапланированного сбоя... >В нынешнем виде неплохо работает ext3fs, >хотя есть более "неплохо работающие" :) Ну есть.Ну ext3.Уже совсем не такой простой когда к нему приделаны всякие там журналы, хэширование директорий и прочие навороты.Зато т.к. все это где-то сбоку приделано - его минусы в виде заурядной скорости работы, ограничений  навроде числа файлов в каталогах и тормозное удаление больших файлов у него никуда не пропали от этого.Реальных плюсов вижу два - отладенная годами ФС и распостраненная.Ну и гибкий выбор режимов журналирования еще - для особо параноидальных есть полный журналинг например, хоть он и тормозной. >То же самое можно сказать и по отношению к ФС с поправкой >на фичастость. Я тоже считаю что хорошее решение слишком сложным быть не должно.А то будет как с рейзером - задуман круто а доделать рейзер4 так и не могут до сих пор.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Архитектура файловой системы btrfs"

Сообщение от Al (??) on 25-Авг-08, 21:06

Лучшая ФС всех времён и народов это ext2. Я просто не понимаю зачем мне может понадобится что-то другое. Возможно огромные серверы с raid и фанатичной заботой о надёжности требуют навороченыых ФС, но на десктопе ext2 - однозначный выбор.

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

	36. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 25-Авг-08, 21:29
	>Лучшая ФС всех времён и народов это ext2. Просто забейте диск на терабайт (нынче майнстрим смещается в сторону 750Гб дисков) и потом некорректно срубите питание разок.Потом расскажете, как вам время fsck у EXT2 :).Хотя-бы уж EXT3 тогда, а?И та не шедевральная.Плоховато по скорости, с рядом ограничений и устаревшим дизайном, структуры ФС занимают значительное место на диске, большие файлы удаляются долго, есть лимиты на число файлов в папке.Как системный раздел - сойдет.Как ФС для больших дисков - очень так себе.Просто на фоне остальных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 23:12
	а некоторые подумают, что ext3 хуже, чем, например, utf. а тем не менее она лучше. она просто из ряда так называемых "традиционных" fs, и для них вовсе не плоха. просто сейчас идет "революция" fs. и это связано не только с увеличением объема hdd (с ним тоже конечно), но и с появлением альтернатив (SSD например) и т.д....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 26-Авг-08, 11:10
	сори s/utf/ufs
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 22:01
	>сори >s/utf/ufs UFS еще более древнючий и дефективный.У них вроде даже общие корни aka какая-то допотопная миниксовская ФС.Но EXT3 до современного состояния дел прокачали немного, хоть и костыльно весьма и не устранив ряд недостатков.Но в UFS и такого нет - просто морально устаревшая ФС с древнючим дизайном в виде "как есть".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 26-Авг-08, 22:49
	ну он тоже меняется. как ext/2/3/4. и bgfile, и log,... ... юзается до сих пор в солярке... теперь вот и zfs :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 26-Авг-08, 08:11
	>>Лучшая ФС всех времён и народов это ext2. >Хотя-бы уж EXT3 тогда, а? Вот именно! :))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Архитектура файловой системы btrfs"
	Сообщение от Имя on 26-Авг-08, 11:41
	"ext3 sucks-by-design" (C) Andrew Morton
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 27-Авг-08, 20:29
	>"ext3 sucks-by-design" (C) Andrew Morton А то ext2 меньше sucks :) но для системного раздела ext3 хватит, а для остальных есть и другие ФС.... ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Архитектура файловой системы btrfs"
	Сообщение от Michael Shigorin (ok) on 26-Авг-08, 12:49
	>Лучшая ФС всех времён и народов это ext2. Это если ничего нет, ничего не нужно и всё это никогда не падает по питанию. >Я просто не понимаю зачем мне может понадобится что-то другое. >Возможно огромные серверы с raid и фанатичной заботой о надёжности >требуют навороченыых ФС, но на десктопе ext2 - однозначный выбор. Восьмилетней давности. home:~> df Filesystem            Size  Used Avail Use% Mounted on /dev/md0              972M  345M  576M  38% / udevfs                5.0M  160K  4.9M   4% /dev /dev/md1               99G   55G   43G  57% /home /dev/sdb1              10G  5.6G  4.5G  56% /usr /dev/sda2             5.1G  712M  4.4G  14% /var /dev/sdb6             350G  292G   59G  84% /var/ftp /dev/sda6             350G  245G  106G  70% /media /dev/sdc8             254G  242G   13G  96% /media/backup /dev/shm              8.0G  338M  7.7G   5% /tmp none                  272M     0  272M   0% /dev/shm Припоминая, сколько мог fsck'ться ext2-раздел гигабайт на тридцать, мне становится дурно при мысли о том, сколько бы впустую лопатился на порядок больший объём.  Хранить рабочий MiniDV-материал на лентах не предлагать ;) PS: для линуксового софтрейда в качестве "журнала" рекомендуется write intent bitmap, см. mdadm(8).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

43. "Архитектура файловой системы btrfs"

Сообщение от Аноним (??) on 25-Авг-08, 23:15

>Плоховато по скорости ext2 в большинстве тестов занимает первые строчки, не знаю кто придумал фигню, что эта ФС медленная. >с рядом ограничений вроде таких: 2 терабайта файл, 32 весь том >как вам время fsck у EXT2 Аккумуляторы у ноута, ИБП и регулярная запись на болванки нужных файлов - это реальная защита информации. Полагаться на надёжность ФС - не лучший вариант. Вообще, судорожно хватать всё новое - основная болезнь современного человека. Очень плохо, когда люди высасывают проблему из пальца, а потом начинают её решать, изобретая тонну костылей.

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

	45. "Архитектура файловой системы btrfs"
	Сообщение от vitek (??) on 25-Авг-08, 23:54
	Вы в общем равы (вздыхая..) но представьте себе раздел, заполненный на 90% файлами средней величины в 30kb, объемом 2000Gb... после этого сами начнёте искать альтернативы... а может и свою fs напишите. в линухе это не так уж и сложно. вот и помелс есть... :-D (не в обиду...)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 26-Авг-08, 10:11
	Да чего тут спорить. Если у человека ненагруженный десктоп со сторэджом порядка 100 Gb ему действительно может хватать ext2/3 (хотя мне не очень понятно как можно мириться с такими тормозами). to Аноним: я вот не знаю, кто придумал такие тесты. Ни разу не получалось воспроизвести похожий результат. ext2 всегда была в аутсайдерах, даже при чистом umount(). Думается, весь этот разговор бесплоден, все эти темы давно перетерты в предыдущих обсуждениях, позиции сторон доказаны цифрами. Не вижу смысла дальше говорить о традиционных ФС. Если кому-то еще не понятно -- будущее за перспективными файловыми системами -- ZFS, btrfs и их не родившимися еще последователями. Это уже поняли Sun, Oracle, FreeBSD development team и парни из Linux kernel project. С каждым днем это понимают все больше пользователей и администраторов. Прогресс, ИМХО, не остановить и консерватизм здесь бесполезен. Да, реально есть машины и задачи, на которых ZFS/btrfs не являются необходимыми -- и так все неплохо работает. Только не стоит на основании этого утверждать, что традиционные ФС лучше и прозводительнее, а перспективные сложны и бесполезны болшинству пользователей. Это не правда, и скаждым днем в этом убезждаются все больше людей. Они производительнее, гибче, надежнее и _гораздо_ удобнее традиционных ФС. Для любых задач, но на более-менее современном железе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 28-Авг-08, 20:11
	>Да чего тут спорить. Если у человека ненагруженный десктоп со сторэджом порядка >100 Gb ему действительно может хватать ext2/3 Я вижу только одну проблему - майнстримовые диски нынче становятся на 750 Gb.Сколько будет чекаться забитый раздел на 750 гиг fsck-ом - даже предположить не берусь. >  С каждым днем это понимают все больше пользователей и администраторов. А куда деваться?Если на десктопе на ширпотребных комплектующих легко можно хранить терабайт а то и больше - возникает резонное такое желание: найти какую-то адекватную управу на такой объем данных.В свете этого решения по управлению томами и т.п. уже не смотрятся оверкиллом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 02-Сен-08, 12:37
	Дык о том и разговор.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 26-Авг-08, 22:32
	>ext2 в большинстве тестов занимает первые строчки, Любой ФС можно грамотно поднасрать :P 1) Берем файл на 4Gb.Стираем файл.Бенчмаркаем потребное на удаление файла время в разных FS.Где там у нас ext2?Правильно, понятно где.Она стирает такой файл несколько секунд (да, несколько секунд стирается ОДИН файл!).Десяток таких файлов будет стираться около минуты.А несчастные 40 гигов - не предел мечтаний с хардом на терабайт... 2) Кладем этак 30 000 файлов в 1 диру.Пробуем поработать с ними.Что, и правда первые строчки?А как же рейзер?Хотя нынче есть небольшой чит с хэшированием директорий но это довесок а потому некоторые противные особенности оригинального дизайна никуда не денется :).А сказав что EXT*2* вы сами запретили юзать хэшинг директорий, он тольако в EXT3 появился.Можно и без него, но на разлапистой структуре каталогов с кучей файлов традиционные каталоги много медленее структур с деревьями - там по задумке скорость работы мало зависит от числа элементов в каталоге и т.п.. 3) Система сильно засирает диск своими инодами.Юзеж места на диске служебными структурами у EXT2 явно не чемпионский.Тут его XFS и JFS весьма сильно обидят. 4) EXT2 не журналирующая ФС так что при внеплановых рестартах будет fsck.На томе в сотни две гигов или крупнее - усраться можно ждать его завершения.А ext3 за счет журнала несколько медленнее.Оно и так то не быстрое, а с журналом - еще более не быстрое. >не знаю кто придумал фигню, что эта ФС медленная. Бенчмарки ФС можно делать по разному.И в зависимости от того как их делать результат может очень сильно меняться.С перетряской лидеров в аутсайдеры и наоборот.Все определяется узкими местами, задачами и тем насколько конкретная ФС хорошо вписывается в задачи.Есть ряд usage pattern для которых энная ФС хорошо подходит.И есть ряд usage pattern для которых энная ФС подходит плохо.Для разных ФС эти usage pattern разные, у них ВСЕХ есть свои сильные и слабые стороны.Например если у вас допустим, RAID, большие файлы и все такое - удачи побить XFS по скорости чтения\записи больших файлов.И, кстати у XFS есть журналинг.Пусть и только для метаданных, но все-таки лучше чем никакого журнала вообще с сопутствующими FSCK на 2 часа. >>с рядом ограничений >вроде таких: 2 терабайта файл, 32 весь том Это кстати по современным меркам означает что через всего несколько лет начнутся проблемы.Ну и лимиты типа 32000 файлов на каталог были простительны кривому фат в 1990 году.А в 2008 извините, архаизм слегка. >>как вам время fsck у EXT2 >Аккумуляторы у ноута, ИБП и регулярная запись на болванки нужных файлов - Спасибо, я предпочитаю просто ext3 на системном разделе юзать, хоть он и чуть медленнее.Аккумуляторы и упсы это круто конечно но shit как известно happens по той или иной причине.И ждать пока у меня будут в случае чего два часа FSCKаться диски (например на домашней машине я преодолел терабайтную отметку) - увольте, это как-нибудь без меня.Разделы для увесистых но редко перезаписываемых данных - XFS там явно рулит.Особенно если с UPSом. >это реальная защита информации. Полагаться на надёжность ФС - не лучший >вариант. Бэкапы никто и не отменял.Я просто не понимаю на кой хрен в 2008 году пользоваться именно ext2.Если ext3 с хэшированием дир - оно вполне себе ничего для системного раздела и т.п.., в том числе и потому что код хорошо отлажен. >изобретая тонну костылей. Понимаете, можно и на лошадях ездить.На телеге.Но медленно и не очень удобно.Тем не менее, когда расстояния начинают измеряться тысячами километров а емкости дисков терабайтами - приходится иногда переоценивать уже существующие ценности.Да, можно сказать "нафиг мне ехать куда-то за 2000 км?Я могу в соседнее село на своей коняге сгонять!".Но это не значит что все разделяют вашу точку зрения.Вот и с хардами так же.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

46. "Архитектура файловой системы btrfs"

Сообщение от vitek (??) on 26-Авг-08, 00:13

на редкость культурный форум! спасибо всем! если кого обидел - не судите строго :-)

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

	51. "Архитектура файловой системы btrfs"
	Сообщение от fresco (??) on 26-Авг-08, 10:13
	присоединяюсь :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

47. "Архитектура файловой системы btrfs"

Сообщение от Аноним (??) on 26-Авг-08, 01:01

А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть контроллеры, для второго LVM

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

	49. "Архитектура файловой системы btrfs"
	Сообщение от www2 (??) on 26-Авг-08, 08:15
	>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть >контроллеры, для второго LVM Это не просто RAID, это очень гибкий RAID :) А снапшоты FS там могут параллельно работать как полноценные файловые системы, хотя зачем это?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Архитектура файловой системы btrfs"
	Сообщение от Аноним (??) on 26-Авг-08, 17:32
	>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть >контроллеры, для второго LVM Включи моск - емнип чтоб не надо было контроллеров и лвм"а :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Архитектура файловой системы btrfs"
	Сообщение от LOL (??) on 27-Авг-08, 17:57
	>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть >контроллеры, для второго LVM Например, на домашнем компе можно использовать аппаратный контроллер (пусть и дорогой), но, имхо, слишком геморно. Уже сколько раз с raid-z (типа Raid5) при ковырянии внутри компа (на гарячую) отключалось одновременно 2 диска (ненадежные контакты, это как никак не серверная железяка). Резет и все дальше работает как пить дать. Для полного удовлетворения scrub-ом пройтись и все как рукой снимает. Как это все лечить на аппаратном контроллере - ума не приложу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "Архитектура файловой системы btrfs"
	Сообщение от pm (??) on 31-Дек-08, 14:57
	>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть >контроллеры, для второго LVM RAID на уровне FS быстрее (файловая система знает что где лежит, да и перезаписываются при замене диска только нужные данные) и гибче (позволяет менять конфигурацию на лету, использовать разные диски). Снапшоты нужны для бэкапов, апдейтов системы (которые можно откатить в случае неудачи). Удобно их использовать и для других вещей - например сборки нескольких версий программы из одних сорцов - создал файловую систему с исходниками, с нее наделал снимков и в каждом запустить make с нужными опциями.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

59. "Архитектура файловой системы btrfs"

Сообщение от Sergey Ivanov on 26-Авг-08, 19:53

Попробовал вчера, /home, /opt, /data  сейчас живут на btrfs. Из тех вещей хороших вещей, к которым привык в zfs, одна в btrfs есть. Могу делать snapshot'ы, могу subvolumes. В конце-концов появилась возможность иметь snapshot и откатиться к нему в любой момент когда понадобится. Второй вещи нет и не предвидится, как я понял, а жаль: zfs может send/receive snapshot'ы, и с ключём -i send передаёт только изменённые блоки, таким образом организуя "incremental snapshots". Увы, с btrfs придётся сканировать все файлы в поисках того, что изменилось. Так что для надёжных хранилищ и быстрых backups пока что единственная альтернатива Солярисному zfs - zfs FreeBSD или MacOS. Или, конечно, хорошие и очень дорогие storage arrays.

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

	71. "Архитектура файловой системы btrfs"
	Сообщение от anonymous (??) on 27-Авг-08, 07:02
	>Так что для надёжных хранилищ и быстрых backups пока что единственная альтернатива Солярисному zfs - zfs FreeBSD или MacOS. Или, конечно, хорошие и очень дорогие storage arrays. методики и рассчёты где? почему гугл эту хрень не использует? видимо у них мало данных хранится
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Архитектура файловой системы btrfs"
	Сообщение от LOL (??) on 27-Авг-08, 11:53
	>методики и рассчёты где? почему гугл эту хрень не использует? видимо у >них мало данных хранится Щас все бросят и начнут на ZFS переходить. Там совсем другие маштабы и требования.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "+про 'совсем другие маштабы и требования'"
	Сообщение от Andrey Mitrofanov on 27-Авг-08, 12:49
	>>Так что для надёжных хранилищ и быстрых backups >почему гугл эту хрень не использует? видимо у них мало данных хранится У Гугла надёжность рализована на другом уровне: отвалился один сервер - ну и zfs с ним, а google.{ru,com} продолжает работать. ...""по самым скромным подсчетам около 200 тысяч серверов [...] Каждый момент от 40 до 80 машин кластера недоступны в сети""...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 28-Авг-08, 16:59
	>методики и рассчёты где? почему гугл эту хрень не использует? Потому что у гугеля много сравнительно недорогих и не монструознах серверов.На линуксе, под который ZFS в нормальном виде для начала вообще нет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 27-Авг-08, 20:44
	> Попробовал вчера, /home, /opt, /data  сейчас живут на btrfs. Мне в прошлый раз OOPSа хватило чтобы не делать таких вещей :).Надо б еще раз погонять но такого безрассудства от меня фиг дождетесь :P >Так что для надёжных хранилищ А в этом то качестве какие к btrfs предъявы?Ну насчет скорости снапшотов я еще понимаю но на именно надежности хранения то это не сказывается, только на времени создания бэкапа. >Солярисному zfs - zfs FreeBSD или MacOS. Это которые недоделаны то?Ага, хорошая альтернатива.После этого заявы советчика советующего недоделанный код про надежные хранилища выглядят каким-то понтом.Вот вы и пользуйте сырые ФС типа btrfs и zfs в бсд для ваших данных если они у вас столь неинтересные что и профукать можно.А я погодю их в продакшне юзать пока их релизом не заявят.Одно дело потестировать их а другое полномасштабно юзать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Архитектура файловой системы btrfs"
	Сообщение от User294 (??) on 28-Авг-08, 18:59
	> Так что для надёжных хранилищ и быстрых backups пока что единственная альтернатива Дык ни BTRFS ни ZFS для *bsd пока как релиз не заявлени и потому альтернатива они только для тех кто хочет их потестировать :).И кстати в упомянутом документе про структуры btrfs сказано что инкрементальные снапшоты сделать не вопрос.То что их СЕЙЧАС нет - да пофиг.Все-равно ФС недоделана еще и не релизного качества.У кого-то проблемы с пониманием того что такое "находится в разработке" и "готово для использования в продакшне"?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

84. "Архитектура файловой системы btrfs"

Сообщение от deepwalker (??) on 28-Окт-08, 01:51

Поигрался с обоими, хочу : ) Хочу понимаешь, чтобы ФС мне вовремя сказала - ай дарагой, что то с твоим диском не то, CRC битый попался!

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

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]