| 1.1, BratSinot (ok), 01:37, 29/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Например, Tux3 известен тем, что в одном из тестов смог обогнать tmpfs, что ранее считалось невозможным, так как tmpfs является довольно тонкой прослойкой между VFS и SWAP.
Стоять, а разве tmpfs не в RAM? Т.е. SWAP это вообще в другую стезю.
| | |
| |
| 2.2, px (??), 01:46, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Судя по выше сказанному tmpfs работает поверх виртуальной памяти (ram+swap), что логичнее, чем сурово забивать оперативку...
| | |
| |
| 3.3, ZuBB (ok), 01:54, 29/03/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
 но если свопа нет, то получается что tmpfs == ram, или не так?
| | |
| |
| 4.4, Аноним (-), 01:56, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Прикол в том что сначала никто не верил что tmpfs вообще можно побить по скорости. А оказалось - МОЖНО.
| | |
| |
| 5.23, анон (?), 13:58, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Скорее всего они получили буст в случае когда tmpfs по-факту в swap. Типа сжатия на лету, а-ля zram.
Чему тут удивляться?
| | |
| 5.30, pavlinux (ok), 16:25, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Например, Tux3 известен тем, что в одном из тестов смог обогнать tmpfs
Дате тесты SYNC RANDOM WRITE!
| | |
| |
| 6.40, Аноним (-), 18:35, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Дате тесты SYNC RANDOM WRITE!
Кстати конкретно этот на них пожалуй даже и не обоcpeтся особо. Ты только представь себе, при запросе на запись он должен 1) пхнуть блок в первое попавшееся свободное место и 2) проапдейтить указатель. Тормозить там особо нечему.
И вообще, CoW/версионники/каквытамэтоназываете - на запись как раз не особо тормозят несмотря на полное журналирование :). Это одна из фич такого подхода.
| | |
| |
| 7.56, pavlinux (ok), 02:50, 30/03/2014 [^] [^^] [^^^] [ответить] | +1 +/– | Вот тут бенчмарк http lkml iu edu hypermail linux kernel 1305 0 03713 html -... большой текст свёрнут, показать | | |
| |
| 8.69, Аноним (-), 03:05, 31/03/2014 [^] [^^] [^^^] [ответить] | +/– | Весьма зависит от оверхеда на сброс служебных структур У tux3 он судя по всему ... текст свёрнут, показать | | |
|
| 7.87, pansa (ok), 01:14, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > И вообще, CoW/версионники/каквытамэтоназываете - на запись как раз не особо тормозят несмотря на полное журналирование
Ога. Дафай, расскажи это тем, у кого сторадж на zfs заполнен на >85%.
| | |
|
|
|
|
|
|
| |
| 2.11, arisu (ok), 06:27, 29/03/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > b-tree изжил себя, фрактальные индексы интереснее
компилятор тебе в руки, за чем дело стало?
| | |
| 2.24, rob pike (?), 14:12, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
А еще ламповые усилители и двухтактные двигатели, ага.
LMDB обгонишь - тогда приходи, поговорим.
| | |
| 2.31, pavlinux (ok), 16:29, 29/03/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> b-tree изжил себя, фрактальные индексы интереснее
Как только DDR будет работать по принципу броуновского движения.
| | |
| 2.36, Аноним (-), 17:30, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> b-tree изжил себя,
Громкое заявление. Ибо довольно фундаментальная структура, на которой много чего держится.
| | |
|
| 1.7, Аноним (-), 04:05, 29/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Да, разумеется включат.
Линус уже давным-давно делает всё, что ему говорят Samsung, Google, HP, IBM, список можете продолжить сами.
| | |
| |
| 2.15, hoopoe (ok), 07:24, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Эти монстры вваливают в линукс столько денег каждый год, сколько простому смертному за всю жизнь не заработать
| | |
| |
| 3.17, Аноним (-), 11:18, 29/03/2014 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Эти монстры вваливают в линукс столько денег каждый год, сколько простому смертному
> за всю жизнь не заработать
Они вкладывают в Linux потому что зарабатывают с помощью него, было бы странно не инвестировать доходную кормушку
| | |
| |
| 4.19, anonymus (?), 11:36, 29/03/2014 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> было бы странно не инвестировать доходную кормушку
Ты не поверишь, но многим эта мысль не приходит в голову. Они предпочитают пилить собственные реализации, чем поддерживать существующие. Как же так - делиться кодом с вероятным противником? Усраться и не поддаться.
| | |
|
|
| 2.27, Аноним (-), 15:00, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Линус уже давным-давно делает всё, что ему говорят Samsung, Google, HP, IBM, список можете продолжить сами.
Линус включает в ядро только грамотные и толковые патчи. А поступают такие патчи - сюрприз! - от профессиональных разработчиков, которые в фуллтайме пишут вещи, полезные не только их работодателям.
| | |
| 2.53, Аноним (-), 01:29, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
В любом случае, разработкой Linux сейчас де факто управляют корпорации.
А я против этого.
| | |
| |
| 3.55, SergMarkov (ok), 02:33, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > В любом случае, разработкой Linux сейчас де факто управляют корпорации.
> А я против этого.
гайка ждет тебя :-)
| | |
| 3.76, Andrew Kolchoogin (ok), 12:30, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > А я против этого.
А что мешает повторить путь Турвалдса? Нопейсать своё ядро, с шахматами и поэтессами, и, как он, популяризировать?
| | |
|
|
| |
| 2.18, Аноним (-), 11:23, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Очень интересная вещь. Будущий конкурент Btrfs, судя по всему.
Я бы так не сказал, поскольку Btrfs уже используют некоторые дистрибутивы, а tux3 имеет на данный момент только слова которые даже тестами не подкреплены. Стабилизация 2 или 3 года, потом активное тестирование, потом внедрение. Btrfs пока немного впереди его уже сипользуют
| | |
| |
| |
| 4.39, Аноним (-), 18:32, 29/03/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Я и сказал: в будущем.
На фичи btrfs vs tux3 форумные аналитики даже не пробовали смотреть. Это слишком сложно, да? :)
| | |
| |
| |
| 6.70, Аноним (-), 03:07, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Btrfs хороша снапшотами, в сабже снапшоты тоже обещают.
"Боинг летает. Вася тоже обещал что его дельтаплан полетит". Следует ли отсюда что дельтаплан Васи и Боинг - одинаковы по возможностям?
| | |
|
|
|
|
| |
| 3.28, Аноним (-), 16:04, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> BTRFS не версионная, насколько я помню.
То есть точно ты не знаешь, верно?
| | |
| |
| 4.49, FractalizeR (ok), 20:36, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 >> BTRFS не версионная, насколько я помню.
> То есть точно ты не знаешь, верно?
Гм... Ну теперь-то я точно знаю :)
| | |
|
| 3.46, Аноним (-), 19:07, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> BTRFS не версионная, насколько я помню.
Она Copy-on-write. Не то чтобы это принципиально отличается - это по сути подвиды одного и того же класса алгоритмов. То-есть общая идея - при записи не гробится старое состояние, вместо этого делается выносок вбок и оформляется новое состояние. Отличия в деталях реализации этой механики, кто-то оптимизирует в одну сторону, кто-то в другую.
| | |
| |
| 4.61, Fracta1L (ok), 11:54, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 В принципе да, при желании версионирование можно впилить в Btrfs, т.к. механизм памяти состояний файла уже реализован.
| | |
| |
| 5.71, Аноним (-), 03:11, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> В принципе да, при желании версионирование можно впилить в Btrfs, т.к. механизм
> памяти состояний файла уже реализован.
Просто это по сути подвиды одной и той же идеи, отличающиеся между собой лишь некоей конкретикой реализации. Считать их принципиально разными IMHO как-то криво.
| | |
|
|
|
| 2.37, Аноним (-), 17:32, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Очень интересная вещь. Будущий конкурент Btrfs, судя по всему.
Скорее, замена ext4. По фичам ему до btrfs как до китая пешком. Но вот версионирование и скорость работы могли бы ему позволить заменить классические EXTы. Все-таки классика не может делать полное журналирование с хорошей скоростью, как ни крути.
| | |
|
| 1.26, Аноним (-), 14:58, 29/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Вижу только безудержное самовосхваление. А реальных результатов - с гулькин хрен.
> Тем не менее, по словам разработчика, потребуется еще порядка 3 лет на оптимизацию, стабилизацию и отладку до уровня при котором станет возможным промышленное внедрение данной файловой системы.
Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода, год, максимум полтора - все будет". Так что реально срок допиливания Tux3 стоит предполагать где-то в году 2020-м.
| | |
| |
| 2.32, pavlinux (ok), 16:37, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вижу только безудержное самовосхваление. А реальных результатов - с гулькин хрен.
Какой универ закончил? Тема диплома? Где работаешь? Должность? Ссылки на работающие проекты?
> так что реально срок допиливания Tux3 стоит предполагать где-то в году 2020-м.
Форумные аналитеги. Ты её хоть пробовал? Тух3 и 5 лет назад рабочим был. И чудесно работал.
| | |
| 2.34, Fracta1L (ok), 16:58, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
> год, максимум полтора - все будет".
А слушать не надо, надо использовать.
| | |
| |
| 3.41, Сергей (??), 18:40, 29/03/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Ога, да Btrfs можно пользоваться, да, только вот по скорости она не шибко быстрая, а что касается надёжности - смотрим changelog сежего стабильного ведра, например 3.10.34 (https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.34) и что мы видим?
Btrfs: fix data corruption when reading/updating compressed extents
Гоп-ца-ца! Сударь, а вы данные не боитесь потерять, если до сих пор в этой поделке обнаруживаются такие ошибки, а?
Не-не, что бы там не говорили нанятые ораклом пиарщики из facebook-а и тд, оно для пром. использования не годится. Да и для домашнего тоже, если нет желания в момент срочной надобности информации хвататься за голову и с криком "профукались мои данные!" прыгать в окно.
| | |
| |
| 4.47, Аноним (-), 19:11, 29/03/2014 [^] [^^] [^^^] [ответить] | +/– | Вот чего-чего а если btrfs использовать - надо использовать свежие кернелы А вы... большой текст свёрнут, показать | | |
| |
| 5.51, Сергей (??), 22:55, 29/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну а бэкапы конечно не для вас.
А Вы лично после каждой файловой операции на боевой машине снимаете бэкап, да?
Ну, а что касается btrfs - у Вас был опыт установки этой фс на боевой nginx-фронтэнд с RPS более 2000 на раздел с горячим кэшем? или может на video on demand - сервер(nginx flv|mp4), который заливает под завязку канал в 2 гбит?
Просто, какбэ огульно утверждать, что у btrfs всё тип-топ, даже под такими нагрузками я бы не стал, ибо лично видел как на таких нагрузках btrfs вставал раком и даже не по производительности, а как раз по стабильности - кернэл паник возникал где-то после получаса - пары часов работы, как раз как сервер полностью загружался юзерами... (ядра январские, все lts с kernel.org).
А вот, например, xfs или старый-добрый ext4 работали как миленькие по полгода и больше.
| | |
| |
| 6.62, Fracta1L (ok), 12:03, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вы бы ещё уточнили, в каком году это было, на каком ядре и с какими параметрами монтирования.
| | |
| 6.72, Аноним (-), 03:21, 31/03/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Нет, разумеется Ну так не каждая файловая операция представляет из себя ценност... большой текст свёрнут, показать | | |
| |
| 7.75, evkogan (?), 11:48, 31/03/2014 [^] [^^] [^^^] [ответить] | +/– | Смешно, Вы это попробуйте паре тысяч пользователей объяснить Это не боевой серв... большой текст свёрнут, показать | | |
|
|
|
|
| |
| 4.64, rafarator (ok), 13:26, 30/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Не знаю как для продакшена (думаю рановато), а для домашней системы использование btrfs очень удобно. К примеру, root на btrfs позволяет быстро проводить обновления в стороне с помощью снапшотов, (пользуюсь генту), и позволяет всегда иметь рабочую ОС нескольких версий без бездумного копирования. :) Это одно из немногих применений, есть еще настройки пользователя на отдельном субволуме и прочие удобства. В общем btrfs я доволен. С интересом гляну на tux, когда появится.
| | |
|
|
| 2.38, Аноним (-), 17:40, 29/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вижу только безудержное самовосхваление. А реальных результатов - с гулькин хрен.
Ну как бы код есть и работает, обслуживая нужды разработчика. А самовосхваление было сугубо по заявкам слушателей и в приватном порядке, если что.
> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
> год, максимум полтора - все будет".
ИЧСХ, уже более-менее есть :).
> Так что реально срок допиливания
> Tux3 стоит предполагать где-то в году 2020-м.
У него желаемый набор фич меньше.
| | |
| |
| 3.43, Сергей (??), 18:47, 29/03/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
>> год, максимум полтора - все будет".
> ИЧСХ, уже более-менее есть :).
Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS - это вроде как клон zFS, то есть планы-то у него такие же - это всё, что касается управление данными на блочных устройствах, то есть полная замена mdadm, lvm, файловой системы + в некотором будущем всего-то распределённая фс (нечто вроде drbd+clvm+gfs2|ocfs2) так что - извините, уважаемый, но скорее "менее есть", чем "более есть".
>> Так что реально срок допиливания
>> Tux3 стоит предполагать где-то в году 2020-м.
> У него желаемый набор фич меньше.
Здесь нет наполеоновских планов, но набор фич заявлен серьёзный и основной функционал _уже_ реализован, так что автор фс реально смотрит на вещи, в отличии от сказочников из оракла.
| | |
| |
| 4.48, Аноним (-), 19:22, 29/03/2014 [^] [^^] [^^^] [ответить] | –2 +/– | По возможностям - да Более того - догнать и перегнать Что они, кстати, уже усп... большой текст свёрнут, показать | | |
| |
| 5.50, Сергей (??), 22:42, 29/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять.
Ась? что, по сети можно вольюмы объединять в файловые системы? или возможна загрузка с btrfs-raid5-тома?
> А если не могут - RAID сам по себе не знает какая копия данных верная.
Да ну? Насколько я в курсах, а мне приходилось не только слышать от коллег (как, видимо автору этого заявления) что mdadm в принципе работает, но и собирать массивы, которые были развалены, в том числе под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Кстати, failed-диски, это как раз те диски за актуальность данных которых то самый рэйд, который "сам по себе не знает какая копия данных верная" не ручается, поэтому и метит такой диск как failed. Кроме того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно сказать какая группа блоков содержит актуальные данные, кроме того восстановить недостающие/повреждённые блоки информации.
А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более чем крепко и хорошо если ведёрко не панкнёт.
А что касается сказочников из оракла - дооо, конечно работает! вопрос только в качестве работы - я, конечно, понимаю, что для Вас потеря данных на продакшне - это какбэ фигня, никто не заметит же, ну а для всех остальных надёжность фс - это один из ключевых параметров. Мало кому хочется копируя один файл попортить или профукать другой, не менее важный, а btrfs как раз этим-то и грешит, особенно под хорошим грузом.
| | |
| |
| 6.60, Аноним (-), 10:59, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Он наверняка не юзает бтрфс, а все возможности по ченджлогам ядра рассказывает.
| | |
| 6.63, Fracta1L (ok), 12:05, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором
> вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший
> такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более
> чем крепко и хорошо если ведёрко не панкнёт.
А вы не сделаете снапшот без COW вообще.
| | |
| 6.77, Andrew Kolchoogin (ok), 12:36, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Да ну? Насколько я в курсах, а мне приходилось не только слышать
> от коллег (как, видимо автору этого заявления) что mdadm в принципе
> работает, но и собирать массивы, которые были развалены, в том числе
> под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих
> рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Это не так важно, пользуны могут подождать часик, им главное -- чтобы их данные целыми оставались.
Важно в MD RAID то, что он корректно транслирует Write Barrier'ы -- DM/LVM, кстати, замечены были за читерством в этом тонком месте.
Соответственно, если читерить с WB, тогда с хорошей вероятностью от того же, от чего развалился MD -- от внезапного Power Failure (от Cord Unplugged бесперебойник не защищает, если что) -- данные на XFS могут превратиться в тыкву. ;)
| | |
| 6.81, Аноним (-), 19:31, 31/03/2014 [^] [^^] [^^^] [ответить] | +/– | Это вообще уже не к дисковой ФС вопросы а к надстройкам над ними На каком-то фу... большой текст свёрнут, показать | | |
|
| 5.74, тигар (ok), 10:34, 31/03/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
 >> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS -
>> это вроде как клон zFS,
> По возможностям - да. Более того - догнать и перегнать. Что они,
> кстати, уже успешно делают. Например в btrfs можно местами отключить CoW,
> если он мешается. А базам данных он как раз мешается. Ибо
> не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая
> к повторной работе на нескольких уровнях, это сажает производительность. Работа с
диванный аналитег не имеет идей что с этим делать, статью на хабарахабар никто не написал по этой "проблеме"? подсказка: те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать, cow им не мешает при этом.
> снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало
> ZFS даже когда пешком под стол ходило, управление кешом - интегрировано
> с ядром, а не как в ZFS.
"не как в zfs под линукс" имелось ввиду, я надеюсь? а где там, кстати, бенчи были, где оно обижало zfs ?
>> Здесь нет наполеоновских планов, но набор фич заявлен серьёзный
> Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти
> все прямо сразу, сугубо за счет принципа работы. Было бы сранно
> их НЕ заявлять при этом.
>> и основной функционал _уже_ реализован, так что автор фс реально смотрит
>> на вещи, в отличии от сказочников из оракла.
> У сказочников из оракла уже работает большинство из фич, которые в tux3
> даже не рискуют заявлять. | | |
| |
| 6.83, Аноним (-), 19:42, 31/03/2014 [^] [^^] [^^^] [ответить] | +/– | Я тоже знаю к доктору на прием записаться Ибо фанатизм окончательно победил зд... большой текст свёрнут, показать | | |
| |
| 7.85, тигар (ok), 00:20, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать,
> Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил
> здравый смысл.
а где ты здесь фанатизм узрел? удобная в управлении fs. ей пользуются.
>> cow им не мешает при этом.
> Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов
> такая мелочь не пугает.
"настоящие фанаты" знают как приготовить это дело так, чтобы не было "работа разможится". на хабарахабаре не пишут что нужно сделать? ну.. попробуй почитать оф. док-цию, например.
>> "не как в zfs под линукс" имелось ввиду, я надеюсь?
> И под Linux, и под бзду. ARC везде одинаково не интегрирован с
> ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там
> конечно адаптируется, но если он сможет жрать большую часть памяти -
> программам попросившим большой блок памяти будет отлуп. А оно такое надо?
на википердии прочел? я вот своими глазами видел как мускл отожрал 70+гб памяти, до этого ее ела zfs. "под бзду", да.
> Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным
> уже не айс.
>> а где там, кстати, бенчи были, где оно обижало zfs ?
> Да в куче мест. И на форониксе, и на еще куче ресурсов.
> Обижало оно даже в лохматом 2010 году, или когда там. С
> тех пор в btrfs впилили немеряно оптимизаций, если что.
авторитетнее тестов похороникса, пожалуй, может быть только твое мнение. xD
| | |
|
|
| 5.78, Andrew Kolchoogin (ok), 12:41, 31/03/2014 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Работа с снапшотами гибче,
Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в ssh, который отресивить на другой машине и развернуть на другой BtrFS?
> экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило,
И где же это оно его там обижало?
> управление кешом - интегрировано с ядром, а не как в ZFS.
Вы про какой кэш?
Если про блочный -- то ШОА?!
Если про ARC -- так это так и задумано.
| | |
| |
| 6.82, Аноним (-), 19:36, 31/03/2014 [^] [^^] [^^^] [ответить] | +/– | Если вы про send и receive - их в btrfs таки сделали Такие вот чудеса науки Да... большой текст свёрнут, показать | | |
| |
| 7.86, тигар (ok), 00:23, 01/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы
> с выдачей памяти - это так и задумано! Но устроит только
> файлсервер, где никаких программ нет. А в остальных местах обломы выделения
> памяти при попытке попросить блок пожирнее - как-то совсем не прикольно.
> Не хочу ничего сказать, но я бы не хотел видеть такую
> логику поведения на десктопе или сервере приложений.
вот скажи, зачем ты свои влажные мечты изливаешь тут?
кратко: ты написал не правду.
| | |
|
|
|
|
|
|
| |
| 2.44, Сергей (??), 18:49, 29/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Снапшетов в линуксе недождаться никогда?
LVM? не? не читали доки?
| | |
| |
| 3.58, Fracta1L (ok), 07:19, 30/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Снапшетов в линуксе недождаться никогда?
> LVM? не? не читали доки?
Там не снапшоты, а жалкое их подобие. Нормальные снапшоты в Линуксе есть только в Btrfs.
| | |
| |
| 4.66, anonymous (??), 16:20, 30/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Есть ещё nilfs2 (на меня не очень хорошее произведение произвела, но может руки кривые), была next3 (но уже похоже померла, под новые ядра модулей уже похоже нет, вроде как планировалась next4, но что-то не видать её), zfs.
| | |
| |
| 5.67, Fracta1L (ok), 20:35, 30/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Единственная нормальная ФС из них - ZFS, но там такой мудрёж со снапшотами и клонами, мне не понравилось.
| | |
| |
| 6.79, Аноним (-), 18:49, 31/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
?!?!?
То есть ты абсолютный дeбил? Ибо проще и логичнее ZFS-ных снапшотов я не видел. Если таковые имеются - имя в студию.
| | |
| |
| 7.84, Аноним (-), 19:43, 31/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> не видел. Если таковые имеются - имя в студию.
В btrfs? Там с снапшотами можно делать больше, а кривых ограничений на работу с ними - меньше :)
| | |
|
|
|
|
|
| 2.45, arisu (ok), 18:51, 29/03/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Снапшетов в линуксе недождаться никогда?
русская языка ты говорить мала-мала?
| | |
|
|
