forum.opennet.ru

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

Оглавление

Файловая система Tux3 вероятно будет добавлена в ядро Linux, opennews (ok), 29-Мрт-14, (0) [смотреть все]

Стоять, а разве tmpfs не в RAM Т е SWAP это вообще в другую стезю , BratSinot (ok), 01:37 , 29-Мрт-14, (1) //

Судя по выше сказанному tmpfs работает поверх виртуальной памяти ram swap , что, px (??), 01:46 , 29-Мрт-14, (2) +1 //

но если свопа нет, то получается что tmpfs ram, или не так , ZuBB (ok), 01:54 , 29-Мрт-14, (3) +3 //

Прикол в том что сначала никто не верил что tmpfs вообще можно побить по скорост, Аноним (-), 01:56 , 29-Мрт-14, (4)

Скорее всего они получили буст в случае когда tmpfs по-факту в swap Типа сжатия, анон (?), 13:58 , 29-Мрт-14, (23) +1
Дате тесты SYNC RANDOM WRITE , pavlinux (ok), 16:25 , 29-Мрт-14, (30)

Кстати конкретно этот на них пожалуй даже и не обоcpeтся особо Ты только предст, Аноним (-), 18:35 , 29-Мрт-14, (40)

Вот тут бенчмарк http lkml iu edu hypermail linux kernel 1305 0 03713 html--, pavlinux (ok), 02:50 , 30-Мрт-14, (56) +1

Весьма зависит от оверхеда на сброс служебных структур У tux3 он судя по всему , Аноним (-), 03:05 , 31-Мрт-14, (69)

Ога Дафай, расскажи это тем, у кого сторадж на zfs заполнен на 85 , pansa (ok), 01:14 , 01-Апр-14, (87)

b-tree изжил себя, фрактальные индексы интереснее, Pelican (?), 03:33 , 29-Мрт-14, (5) –4 //

https www youtube com watch v 88NaRUdoWZM, Pelican (?), 03:33 , 29-Мрт-14, (6)
компилятор тебе в руки, за чем дело стало , arisu (ok), 06:27 , 29-Мрт-14, (11) +3
А еще ламповые усилители и двухтактные двигатели, ага LMDB обгонишь - тогда прих, rob pike (?), 14:12 , 29-Мрт-14, (24) +1
Как только DDR будет работать по принципу броуновского движения , pavlinux (ok), 16:29 , 29-Мрт-14, (31) +2
Громкое заявление Ибо довольно фундаментальная структура, на которой много чего, Аноним (-), 17:30 , 29-Мрт-14, (36) +1

Да, разумеется включат Линус уже давным-давно делает всё, что ему говорят Samsu, Аноним (-), 04:05 , 29-Мрт-14, (7) //

Эти монстры вваливают в линукс столько денег каждый год, сколько простому смертн, hoopoe (ok), 07:24 , 29-Мрт-14, (15) //

Они вкладывают в Linux потому что зарабатывают с помощью него, было бы странно н, Аноним (-), 11:18 , 29-Мрт-14, (17) +6 //

Ты не поверишь, но многим эта мысль не приходит в голову Они предпочитают пилит, anonymus (?), 11:36 , 29-Мрт-14, (19) +5

Линус включает в ядро только грамотные и толковые патчи А поступают такие патчи, Аноним (-), 15:00 , 29-Мрт-14, (27) +1
В любом случае, разработкой Linux сейчас де факто управляют корпорации А я проти, Аноним (-), 01:29 , 30-Мрт-14, (53) –1 //

гайка ждет тебя - , SergMarkov (ok), 02:33 , 30-Мрт-14, (55) –1 //

Какой Гайка , Аноним (-), 08:03 , 30-Мрт-14, (59)

Полагаю, Haiku OS, ryoken (?), 13:54 , 30-Мрт-14, (65)

А может из Чип и Дейл , Аноним (-), 22:00 , 30-Мрт-14, (68)

А что мешает повторить путь Турвалдса Нопейсать своё ядро, с шахматами и поэтес, Andrew Kolchoogin (ok), 12:30 , 31-Мрт-14, (76)

Нет, будет тебя слушать , Аноним (-), 04:13 , 29-Мрт-14, (8) +2
Очень интересная вещь Будущий конкурент Btrfs, судя по всему , Fracta1L (ok), 06:32 , 29-Мрт-14, (13) –2 //

Я бы так не сказал, поскольку Btrfs уже используют некоторые дистрибутивы, а tux, Аноним (-), 11:23 , 29-Мрт-14, (18) //

Я и сказал в будущем , Fracta1L (ok), 16:58 , 29-Мрт-14, (33) –1 //

На фичи btrfs vs tux3 форумные аналитики даже не пробовали смотреть Это слишком, Аноним (-), 18:32 , 29-Мрт-14, (39) +2

Btrfs хороша снапшотами, в сабже снапшоты тоже обещают , Fracta1L (ok), 07:16 , 30-Мрт-14, (57)

Боинг летает Вася тоже обещал что его дельтаплан полетит Следует ли отсюда ч, Аноним (-), 03:07 , 31-Мрт-14, (70)

BTRFS не версионная, насколько я помню , FractalizeR (ok), 11:39 , 29-Мрт-14, (20) +1 //

То есть точно ты не знаешь, верно , Аноним (-), 16:04 , 29-Мрт-14, (28) //

Гм Ну теперь-то я точно знаю , FractalizeR (ok), 20:36 , 29-Мрт-14, (49)

Она Copy-on-write Не то чтобы это принципиально отличается - это по сути подвид, Аноним (-), 19:07 , 29-Мрт-14, (46) //

В принципе да, при желании версионирование можно впилить в Btrfs, т к механизм , Fracta1L (ok), 11:54 , 30-Мрт-14, (61) –1

Просто это по сути подвиды одной и той же идеи, отличающиеся между собой лишь не, Аноним (-), 03:11 , 31-Мрт-14, (71)

Скорее, замена ext4 По фичам ему до btrfs как до китая пешком Но вот версионир, Аноним (-), 17:32 , 29-Мрт-14, (37)

Вижу только безудержное самовосхваление А реальных результатов - с гулькин хрен, Аноним (-), 14:58 , 29-Мрт-14, (26) –1 //

Какой универ закончил Тема диплома Где работаешь Должность Ссылки на работаю, pavlinux (ok), 16:37 , 29-Мрт-14, (32) +1
А слушать не надо, надо использовать , Fracta1L (ok), 16:58 , 29-Мрт-14, (34) +1
BTRFS уже можно пользоваться , anonymous (??), 17:29 , 29-Мрт-14, (35) //

Ога, да Btrfs можно пользоваться, да, только вот по скорости она не шибко быстра, Сергей (??), 18:40 , 29-Мрт-14, (41) –2 //

Вот чего-чего а если btrfs использовать - надо использовать свежие кернелы А вы , Аноним (-), 19:11 , 29-Мрт-14, (47)

А Вы лично после каждой файловой операции на боевой машине снимаете бэкап, да Ну, Сергей (??), 22:55 , 29-Мрт-14, (51)

Вы бы ещё уточнили, в каком году это было, на каком ядре и с какими параметрами , Fracta1L (ok), 12:03 , 30-Мрт-14, (62) –1
Нет, разумеется Ну так не каждая файловая операция представляет из себя ценност, Аноним (-), 03:21 , 31-Мрт-14, (72) –1

Смешно, Вы это попробуйте паре тысяч пользователей объяснить Это не боевой серве, evkogan (?), 11:48 , 31-Мрт-14, (75)

Тонко , AnonuS (?), 01:22 , 30-Мрт-14, (52) //

Не знаю как для продакшена думаю рановато , а для домашней системы использовани, rafarator (ok), 13:26 , 30-Мрт-14, (64)

Ну как бы код есть и работает, обслуживая нужды разработчика А самовосхваление , Аноним (-), 17:40 , 29-Мрт-14, (38) +1 //

Конечно, есть Только вот один ма-а-аленький момент упустили из виду BtrFS - это, Сергей (??), 18:47 , 29-Мрт-14, (43) –2 //

По возможностям - да Более того - догнать и перегнать Что они, кстати, уже усп, Аноним (-), 19:22 , 29-Мрт-14, (48) –2

Ась что, по сети можно вольюмы объединять в файловые системы или возможна загр, Сергей (??), 22:42 , 29-Мрт-14, (50) –1

Он наверняка не юзает бтрфс, а все возможности по ченджлогам ядра рассказывает , Аноним (-), 10:59 , 30-Мрт-14, (60) –1
А вы не сделаете снапшот без COW вообще , Fracta1L (ok), 12:05 , 30-Мрт-14, (63) –1
Это не так важно, пользуны могут подождать часик, им главное -- чтобы их данные , Andrew Kolchoogin (ok), 12:36 , 31-Мрт-14, (77) –1
Это вообще уже не к дисковой ФС вопросы а к надстройкам над ними На каком-то фун, Аноним (-), 19:31 , 31-Мрт-14, (81)

диванный аналитег не имеет идей что с этим делать, статью на хабарахабар никто н, тигар (ok), 10:34 , 31-Мрт-14, (74) –2

Я тоже знаю к доктору на прием записаться Ибо фанатизм окончательно победил зд, Аноним (-), 19:42 , 31-Мрт-14, (83)

а где ты здесь фанатизм узрел удобная в управлении fs ей пользуются настоящие, тигар (ok), 00:20 , 01-Апр-14, (85)

Поподробнее, пожалуйста В BtrFS можно засендить снэпшот в стрим, который заверн, Andrew Kolchoogin (ok), 12:41 , 31-Мрт-14, (78) –2

Конечно - https btrfs wiki kernel org index php Main_Page Features, А ты как думал (?), 19:28 , 31-Мрт-14, (80)
Если вы про send и receive - их в btrfs таки сделали Такие вот чудеса науки Да , Аноним (-), 19:36 , 31-Мрт-14, (82)

вот скажи, зачем ты свои влажные мечты изливаешь тут кратко ты написал не прав, тигар (ok), 00:23 , 01-Апр-14, (86)

Снапшетов в линуксе недождаться никогда , Аноним (-), 18:46 , 29-Мрт-14, (42) –1 //

LVM не не читали доки , Сергей (??), 18:49 , 29-Мрт-14, (44) –1 //

Там не снапшоты, а жалкое их подобие Нормальные снапшоты в Линуксе есть только , Fracta1L (ok), 07:19 , 30-Мрт-14, (58) //

Есть ещё nilfs2 на меня не очень хорошее произведение произвела, но может руки , anonymous (??), 16:20 , 30-Мрт-14, (66)

Единственная нормальная ФС из них - ZFS, но там такой мудрёж со снапшотами и кло, Fracta1L (ok), 20:35 , 30-Мрт-14, (67) –1

То есть ты абсолютный дeбил Ибо проще и логичнее ZFS-ных снапшотов я не в, Аноним (-), 18:49 , 31-Мрт-14, (79) –1

В btrfs Там с снапшотами можно делать больше, а кривых ограничений на работу с , Аноним (-), 19:43 , 31-Мрт-14, (84)

русская языка ты говорить мала-мала , arisu (ok), 18:51 , 29-Мрт-14, (45) +2

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

43. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –2 +/–

Сообщение от Сергей (??), 29-Мрт-14, 18:47

>> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода,
>> год, максимум полтора - все будет".
> ИЧСХ, уже более-менее есть :).
Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS - это вроде как клон zFS, то есть планы-то у него такие же - это всё, что касается управление данными на блочных устройствах, то есть полная замена mdadm, lvm, файловой системы + в некотором будущем всего-то распределённая фс (нечто вроде drbd+clvm+gfs2|ocfs2) так что - извините, уважаемый, но скорее "менее есть", чем "более есть".
>> Так что реально срок допиливания
>> Tux3 стоит предполагать где-то в году 2020-м.
> У него желаемый набор фич меньше.
Здесь нет наполеоновских планов, но набор фич заявлен серьёзный и основной функционал _уже_ реализован, так что автор фс реально смотрит на вещи, в отличии от сказочников из оракла.

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

48. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –2 +/–

Сообщение от Аноним (-), 29-Мрт-14, 19:22

> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS -
> это вроде как клон zFS,
По возможностям - да. Более того - догнать и перегнать. Что они, кстати, уже успешно делают. Например в btrfs можно местами отключить CoW, если он мешается. А базам данных он как раз мешается. Ибо не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая к повторной работе на нескольких уровнях, это сажает производительность. Работа с снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило, управление кешом - интегрировано с ядром, а не как в ZFS.
> то есть полная замена mdadm, lvm, файловой системы +
Ну да. Это дает некие специфичные плюсы. Ну и некие специфичные минусы. Ну например, видит такой монстрик по ошибке чексуммы - ой, побились данные. Может слазить на другую копию RAID и посмотреть не прокатит ли чексумма если данные взять оттуда. Если прокатит - отлично, починили данные на автомате из исправной копии. Это если ФС и RAID плотно повзаимодействовать могут. А если не могут - RAID сам по себе не знает какая копия данных верная.
> Здесь нет наполеоновских планов, но набор фич заявлен серьёзный
Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти все прямо сразу, сугубо за счет принципа работы. Было бы сранно их НЕ заявлять при этом.
> и основной функционал _уже_ реализован, так что автор фс реально смотрит
> на вещи, в отличии от сказочников из оракла.
У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять.

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

50. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –1 +/–

Сообщение от Сергей (??), 29-Мрт-14, 22:42

> У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять.
Ась? что, по сети можно вольюмы объединять в файловые системы? или возможна загрузка с btrfs-raid5-тома?
> А если не могут - RAID сам по себе не знает какая копия данных верная.
Да ну? Насколько я в курсах, а мне приходилось не только слышать от коллег (как, видимо автору этого заявления) что mdadm в принципе работает, но и собирать массивы, которые были развалены, в том числе под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Кстати, failed-диски, это как раз те диски за актуальность данных которых то самый рэйд, который "сам по себе не знает какая копия данных верная" не ручается, поэтому и метит такой диск как failed. Кроме того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно сказать какая группа блоков содержит актуальные данные, кроме того восстановить недостающие/повреждённые блоки информации.
А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более чем крепко и хорошо если ведёрко не панкнёт.
А что касается сказочников из оракла - дооо, конечно работает! вопрос только в качестве работы - я, конечно, понимаю, что для Вас потеря данных на продакшне - это какбэ фигня, никто не заметит же, ну а для всех остальных надёжность фс - это один из ключевых параметров. Мало кому хочется копируя один файл попортить или профукать другой, не менее важный, а btrfs как раз этим-то и грешит, особенно под хорошим грузом.

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

60. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –1 +/–

Сообщение от Аноним (-), 30-Мрт-14, 10:59

Он наверняка не юзает бтрфс, а все возможности по ченджлогам ядра рассказывает.

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

63. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –1 +/–

Сообщение от Fracta1L (ok), 30-Мрт-14, 12:05

> А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором
> вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший
> такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более
> чем крепко и хорошо если ведёрко не панкнёт.
А вы не сделаете снапшот без COW вообще.

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

77. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –1 +/–

Сообщение от Andrew Kolchoogin (ok), 31-Мрт-14, 12:36

> Да ну? Насколько я в курсах, а мне приходилось не только слышать
> от коллег (как, видимо автору этого заявления) что mdadm в принципе
> работает, но и собирать массивы, которые были развалены, в том числе
> под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих
> рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Это не так важно, пользуны могут подождать часик, им главное -- чтобы их данные целыми оставались.
Важно в MD RAID то, что он корректно транслирует Write Barrier'ы -- DM/LVM, кстати, замечены были за читерством в этом тонком месте.
Соответственно, если читерить с WB, тогда с хорошей вероятностью от того же, от чего развалился MD -- от внезапного Power Failure (от Cord Unplugged бесперебойник не защищает, если что) -- данные на XFS могут превратиться в тыкву. ;)

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

81. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" +/–

Сообщение от Аноним (-), 31-Мрт-14, 19:31

> Ась? что, по сети можно вольюмы объединять в файловые системы?
Это вообще уже не к дисковой ФС вопросы а к надстройкам над ними.
> или возможна загрузка с btrfs-raid5-тома?
На каком-то фундаментальном уровне не вижу чему это будет противоречить. Если бутлоадер может прочесть ядро и рамдиск, разумеется. Linux можно грузить вообще с любой похабщины, ему самому по себе все-равно и там возможностей по костылированию странных вещей в процессе загрузки - хоть отбавляй. Так что если кому сильно надо - имхо сделают. Может и с костылями, да. Вот только для начала, код RAID5/6 в ядре без году неделю и он был добавлен как нестабильный. Я бы им пока вообще не пользовался. Он сырой и грабельный. Хотя если хочется получть граблями по лбу и показательно демонстрировать шишку - вы по адресу. Особенно хорошо получится если взять ядро подревнее, без багфиксов в этом коде. В самых первых ядрах там журналирование с райдом работало некорректно. Так что вы берите ваши суперстабильные, LTSные, как раз получите термоядерный стабилизец с нефикшеным кодом райдов, если фиксы не портировали.
> от коллег (как, видимо автору этого заявления) что mdadm в принципе
> работает, но и собирать массивы, которые были развалены, в том числе
> под нагрузкой, ничего, норм собиралось,
Понятно. На уровне алгоритмов вы по нулям. Если данные на дисках разошлись, RAID не знает какая из копий правильная. Как минимум зеркало и raid5 - точно. Там нет чексумм в их нормальном понимании. Поэтому если диск не сдох совсем, а начал подвирать в выдаваемых данных - это само по себе обнаружено на уровне RAID не будет. А науке известны самые разные глюки, от "вернул не тот сектор" до "ошибка чтения проскочила через CRC/ECC как правильные данные" или "фирмваре сдурело и вернуло шум океанов марса".
> рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке.
Ваше мямление говорит о том что вы не в курсе как это работает. FAIL.
> того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно
> сказать какая группа блоков содержит актуальные данные,
А вы давно смотрели как тот же RAID5 сделан? Там вообще-то данные на дисках + избыточный XOR на n+1 по ширине блоке. Если какой-то диск совсем выпал, путем нехитрой математики восстанавливается что выпавший блок данных (с использованием XOR блока), что сам блок с XOR (с использованием блоков данныз). Вот только для этого надо знать что диск проблемный и игнорировать его, считая его данные отсутствующими. А если диск скажем подвирает в данных - тут уже возможны варианты. Логика работы RAID5 не предусматривает данный случай и полноценный рекавери из него. Даже если мы видим что N блоков != XOR, мы не знаем какой из дисков нам соврал. При этом есть несколько вариантов какими на самом деле были данные. Неверными может быть как каждый из блоков данных, так и XOR-блок. Нет никакого способа узнать какой из вариантов на самом деле был правильный. Если ФС подыграет, отдельно храня чексумму - можно опробовать все варианты и понять какой из них ведет к корректной чексумме. Но это требует хранения какой-то относительно компактной и надежной чексуммы где-то сбоку, это не про простые блочные RAID.
> кроме того восстановить недостающие/повреждённые блоки информации.
Недостающие - может. А вот с повреждениями - см. выше.
> А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер
А это зачем? У БД обычно есть своя журнальная логика, сделанная под вполне конкретные допущения. Снапшотить сие - затея странная. А вы вообще понимаете что будет с базой после отката снапшота, для начала? База уже сказала клиентам в рамках транзакционной модели "вот это записано!". Пришел кулсисоп. Откатил снапшот. Записи испарились. Но клиенту то сказали что все записано. Хорошая идея. Был у меня миллион на счете. Я его снял. А тут база забывает что я транзакцию сделал. Очень удобно: у меня снова миллион на счете. Как вы думаете, сколько вам вазелина потребуется? :)
> А что касается сказочников из оракла - дооо, конечно работает!
Пока-что я детектировал тут другого сказочника, который снапшотит базы данных и восстанавливает во всех случаях данные глупными блочными RAIDами.
> данных на продакшне - это какбэ фигня, никто не заметит же,
Так сабж как раз об этом.
> особенно под хорошим грузом.
Кэп намекает что сабж как раз для того и затеян. И да, ваши репорты давностью в квартал с вашим стабилизцом имеют околонулевую ценность когда вопрос о WIP. Если с того момента вышло 3-4 новых ядра - результаты тестирования на мегастабильном ядре (с бажным кодом btrfs) - вообще ни о чем.

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

74. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –2 +/–

Сообщение от тигар (ok), 31-Мрт-14, 10:34

>> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS -
>> это вроде как клон zFS,
> По возможностям - да. Более того - догнать и перегнать. Что они,
> кстати, уже успешно делают. Например в btrfs можно местами отключить CoW,
> если он мешается. А базам данных он как раз мешается. Ибо
> не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая
> к повторной работе на нескольких уровнях, это сажает производительность. Работа с
диванный аналитег не имеет идей что с этим делать, статью на хабарахабар никто не написал по этой "проблеме"? подсказка: те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать, cow им не мешает при этом.
> снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало
> ZFS даже когда пешком под стол ходило, управление кешом - интегрировано
> с ядром, а не как в ZFS.
"не как в zfs под линукс" имелось ввиду, я надеюсь? а где там, кстати, бенчи были, где оно обижало zfs ?
>> Здесь нет наполеоновских планов, но набор фич заявлен серьёзный
> Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти
> все прямо сразу, сугубо за счет принципа работы. Было бы сранно
> их НЕ заявлять при этом.
>> и основной функционал _уже_ реализован, так что автор фс реально смотрит
>> на вещи, в отличии от сказочников из оракла.
> У сказочников из оракла уже работает большинство из фич, которые в tux3
> даже не рискуют заявлять.

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

83. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" +/–

Сообщение от Аноним (-), 31-Мрт-14, 19:42

> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать,
Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил здравый смысл.
> cow им не мешает при этом.
Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов такая мелочь не пугает.
> "не как в zfs под линукс" имелось ввиду, я надеюсь?
И под Linux, и под бзду. ARC везде одинаково не интегрирован с ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там конечно адаптируется, но если он сможет жрать большую часть памяти - программам попросившим большой блок памяти будет отлуп. А оно такое надо? Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным уже не айс.
> а где там, кстати, бенчи были, где оно обижало zfs ?
Да в куче мест. И на форониксе, и на еще куче ресурсов. Обижало оно даже в лохматом 2010 году, или когда там. С тех пор в btrfs впилили немеряно оптимизаций, если что.

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

85. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" +/–

Сообщение от тигар (ok), 01-Апр-14, 00:20

>> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать,
> Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил
> здравый смысл.
а где ты здесь фанатизм узрел? удобная в управлении fs. ей пользуются.
>> cow им не мешает при этом.
> Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов
> такая мелочь не пугает.
"настоящие фанаты" знают как приготовить это дело так, чтобы не было "работа разможится". на хабарахабаре не пишут что нужно сделать? ну.. попробуй почитать оф. док-цию, например.
>> "не как в zfs под линукс" имелось ввиду, я надеюсь?
> И под Linux, и под бзду. ARC везде одинаково не интегрирован с
> ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там
> конечно адаптируется, но если он сможет жрать большую часть памяти -
> программам попросившим большой блок памяти будет отлуп. А оно такое надо?
на википердии прочел? я вот своими глазами видел как мускл отожрал 70+гб памяти, до этого ее ела zfs. "под бзду", да.
> Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным
> уже не айс.
>> а где там, кстати, бенчи были, где оно обижало zfs ?
> Да в куче мест. И на форониксе, и на еще куче ресурсов.
> Обижало оно даже в лохматом 2010 году, или когда там. С
> тех пор в btrfs впилили немеряно оптимизаций, если что.
авторитетнее тестов похороникса, пожалуй, может быть только твое мнение. xD

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

78. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" –2 +/–

Сообщение от Andrew Kolchoogin (ok), 31-Мрт-14, 12:41

> Работа с снапшотами гибче,
Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в ssh, который отресивить на другой машине и развернуть на другой BtrFS?
> экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило,
И где же это оно его там обижало?
> управление кешом - интегрировано с ядром, а не как в ZFS.
Вы про какой кэш?
Если про блочный -- то ШОА?!
Если про ARC -- так это так и задумано.

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

80. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" +/–

Сообщение от А ты как думал (?), 31-Мрт-14, 19:28

Конечно - https://btrfs.wiki.kernel.org/index.php/Main_Page#Features

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

82. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" +/–

Сообщение от Аноним (-), 31-Мрт-14, 19:36

> Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в
> ssh, который отресивить на другой машине и развернуть на другой BtrFS?
Если вы про send и receive - их в btrfs таки сделали. Такие вот чудеса науки.

> И где же это оно его там обижало?
Да даже на форониксе, как и в любых иных бенчах. Еще в 2010 году аж. А с тех пор нехило подтянули.
> Если про ARC -- так это так и задумано.
Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы с выдачей памяти - это так и задумано! Но устроит только файлсервер, где никаких программ нет. А в остальных местах обломы выделения памяти при попытке попросить блок пожирнее - как-то совсем не прикольно. Не хочу ничего сказать, но я бы не хотел видеть такую логику поведения на десктопе или сервере приложений.

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

86. "Файловая система Tux3 вероятно будет добавлена в ядро Linux" +/–

Сообщение от тигар (ok), 01-Апр-14, 00:23

> Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы
> с выдачей памяти - это так и задумано! Но устроит только
> файлсервер, где никаких программ нет. А в остальных местах обломы выделения
> памяти при попытке попросить блок пожирнее - как-то совсем не прикольно.
> Не хочу ничего сказать, но я бы не хотел видеть такую
> логику поведения на десктопе или сервере приложений.
вот скажи, зачем ты свои влажные мечты изливаешь тут?
кратко: ты написал не правду.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	43. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–2 +/–
	Сообщение от Сергей (??), 29-Мрт-14, 18:47
	>> Уже наверное лет пять слушаем сторонников btrfs, которые говорят "ну через полгода, >> год, максимум полтора - все будет". > ИЧСХ, уже более-менее есть :). Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS - это вроде как клон zFS, то есть планы-то у него такие же - это всё, что касается управление данными на блочных устройствах, то есть полная замена mdadm, lvm, файловой системы + в некотором будущем всего-то распределённая фс (нечто вроде drbd+clvm+gfs2\|ocfs2) так что - извините, уважаемый, но скорее "менее есть", чем "более есть". >> Так что реально срок допиливания >> Tux3 стоит предполагать где-то в году 2020-м. > У него желаемый набор фич меньше. Здесь нет наполеоновских планов, но набор фич заявлен серьёзный и основной функционал _уже_ реализован, так что автор фс реально смотрит на вещи, в отличии от сказочников из оракла.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–2 +/–
	Сообщение от Аноним (-), 29-Мрт-14, 19:22
	> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS - > это вроде как клон zFS, По возможностям - да. Более того - догнать и перегнать. Что они, кстати, уже успешно делают. Например в btrfs можно местами отключить CoW, если он мешается. А базам данных он как раз мешается. Ибо не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая к повторной работе на нескольких уровнях, это сажает производительность. Работа с снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило, управление кешом - интегрировано с ядром, а не как в ZFS. > то есть полная замена mdadm, lvm, файловой системы + Ну да. Это дает некие специфичные плюсы. Ну и некие специфичные минусы. Ну например, видит такой монстрик по ошибке чексуммы - ой, побились данные. Может слазить на другую копию RAID и посмотреть не прокатит ли чексумма если данные взять оттуда. Если прокатит - отлично, починили данные на автомате из исправной копии. Это если ФС и RAID плотно повзаимодействовать могут. А если не могут - RAID сам по себе не знает какая копия данных верная. > Здесь нет наполеоновских планов, но набор фич заявлен серьёзный Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти все прямо сразу, сугубо за счет принципа работы. Было бы сранно их НЕ заявлять при этом. > и основной функционал _уже_ реализован, так что автор фс реально смотрит > на вещи, в отличии от сказочников из оракла. У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–1 +/–
	Сообщение от Сергей (??), 29-Мрт-14, 22:42
	> У сказочников из оракла уже работает большинство из фич, которые в tux3 даже не рискуют заявлять. Ась? что, по сети можно вольюмы объединять в файловые системы? или возможна загрузка с btrfs-raid5-тома? > А если не могут - RAID сам по себе не знает какая копия данных верная. Да ну? Насколько я в курсах, а мне приходилось не только слышать от коллег (как, видимо автору этого заявления) что mdadm в принципе работает, но и собирать массивы, которые были развалены, в том числе под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке. Кстати, failed-диски, это как раз те диски за актуальность данных которых то самый рэйд, который "сам по себе не знает какая копия данных верная" не ручается, поэтому и метит такой диск как failed. Кроме того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно сказать какая группа блоков содержит актуальные данные, кроме того восстановить недостающие/повреждённые блоки информации. А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более чем крепко и хорошо если ведёрко не панкнёт. А что касается сказочников из оракла - дооо, конечно работает! вопрос только в качестве работы - я, конечно, понимаю, что для Вас потеря данных на продакшне - это какбэ фигня, никто не заметит же, ну а для всех остальных надёжность фс - это один из ключевых параметров. Мало кому хочется копируя один файл попортить или профукать другой, не менее важный, а btrfs как раз этим-то и грешит, особенно под хорошим грузом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–1 +/–
	Сообщение от Аноним (-), 30-Мрт-14, 10:59
	Он наверняка не юзает бтрфс, а все возможности по ченджлогам ядра рассказывает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–1 +/–
	Сообщение от Fracta1L (ok), 30-Мрт-14, 12:05
	> А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер (на котором > вы таки отключили CoW у btrfs) и попробуйте смудачить снэпшот, хороший > такой полноценный снэпшот, думаю в процессе у вас сервер приздумается более > чем крепко и хорошо если ведёрко не панкнёт. А вы не сделаете снапшот без COW вообще.
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	77. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–1 +/–
	Сообщение от Andrew Kolchoogin (ok), 31-Мрт-14, 12:36
	> Да ну? Насколько я в курсах, а мне приходилось не только слышать > от коллег (как, видимо автору этого заявления) что mdadm в принципе > работает, но и собирать массивы, которые были развалены, в том числе > под нагрузкой, ничего, норм собиралось, даже фс, которая была поверх этих > рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке. Это не так важно, пользуны могут подождать часик, им главное -- чтобы их данные целыми оставались. Важно в MD RAID то, что он корректно транслирует Write Barrier'ы -- DM/LVM, кстати, замечены были за читерством в этом тонком месте. Соответственно, если читерить с WB, тогда с хорошей вероятностью от того же, от чего развалился MD -- от внезапного Power Failure (от Cord Unplugged бесперебойник не защищает, если что) -- данные на XFS могут превратиться в тыкву. ;)
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	81. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	+/–
	Сообщение от Аноним (-), 31-Мрт-14, 19:31
	> Ась? что, по сети можно вольюмы объединять в файловые системы? Это вообще уже не к дисковой ФС вопросы а к надстройкам над ними. > или возможна загрузка с btrfs-raid5-тома? На каком-то фундаментальном уровне не вижу чему это будет противоречить. Если бутлоадер может прочесть ядро и рамдиск, разумеется. Linux можно грузить вообще с любой похабщины, ему самому по себе все-равно и там возможностей по костылированию странных вещей в процессе загрузки - хоть отбавляй. Так что если кому сильно надо - имхо сделают. Может и с костылями, да. Вот только для начала, код RAID5/6 в ядре без году неделю и он был добавлен как нестабильный. Я бы им пока вообще не пользовался. Он сырой и грабельный. Хотя если хочется получть граблями по лбу и показательно демонстрировать шишку - вы по адресу. Особенно хорошо получится если взять ядро подревнее, без багфиксов в этом коде. В самых первых ядрах там журналирование с райдом работало некорректно. Так что вы берите ваши суперстабильные, LTSные, как раз получите термоядерный стабилизец с нефикшеным кодом райдов, если фиксы не портировали. > от коллег (как, видимо автору этого заявления) что mdadm в принципе > работает, но и собирать массивы, которые были развалены, в том числе > под нагрузкой, ничего, норм собиралось, Понятно. На уровне алгоритмов вы по нулям. Если данные на дисках разошлись, RAID не знает какая из копий правильная. Как минимум зеркало и raid5 - точно. Там нет чексумм в их нормальном понимании. Поэтому если диск не сдох совсем, а начал подвирать в выдаваемых данных - это само по себе обнаружено на уровне RAID не будет. А науке известны самые разные глюки, от "вернул не тот сектор" до "ошибка чтения проскочила через CRC/ECC как правильные данные" или "фирмваре сдурело и вернуло шум океанов марса". > рассыпавшихся рэйдов на ошибки не натыкалась, что говорит о правильной сборке. Ваше мямление говорит о том что вы не в курсе как это работает. FAIL. > того в 5-м и 6-м рэйдах есть чексуммы, по которым-таки можно > сказать какая группа блоков содержит актуальные данные, А вы давно смотрели как тот же RAID5 сделан? Там вообще-то данные на дисках + избыточный XOR на n+1 по ширине блоке. Если какой-то диск совсем выпал, путем нехитрой математики восстанавливается что выпавший блок данных (с использованием XOR блока), что сам блок с XOR (с использованием блоков данныз). Вот только для этого надо знать что диск проблемный и игнорировать его, считая его данные отсутствующими. А если диск скажем подвирает в данных - тут уже возможны варианты. Логика работы RAID5 не предусматривает данный случай и полноценный рекавери из него. Даже если мы видим что N блоков != XOR, мы не знаем какой из дисков нам соврал. При этом есть несколько вариантов какими на самом деле были данные. Неверными может быть как каждый из блоков данных, так и XOR-блок. Нет никакого способа узнать какой из вариантов на самом деле был правильный. Если ФС подыграет, отдельно храня чексумму - можно опробовать все варианты и понять какой из них ведет к корректной чексумме. Но это требует хранения какой-то относительно компактной и надежной чексуммы где-то сбоку, это не про простые блочные RAID. > кроме того восстановить недостающие/повреждённые блоки информации. Недостающие - может. А вот с повреждениями - см. выше. > А что касается снэпшотов - уважаемый, возьмите хорошо прогруженный БД-сервер А это зачем? У БД обычно есть своя журнальная логика, сделанная под вполне конкретные допущения. Снапшотить сие - затея странная. А вы вообще понимаете что будет с базой после отката снапшота, для начала? База уже сказала клиентам в рамках транзакционной модели "вот это записано!". Пришел кулсисоп. Откатил снапшот. Записи испарились. Но клиенту то сказали что все записано. Хорошая идея. Был у меня миллион на счете. Я его снял. А тут база забывает что я транзакцию сделал. Очень удобно: у меня снова миллион на счете. Как вы думаете, сколько вам вазелина потребуется? :) > А что касается сказочников из оракла - дооо, конечно работает! Пока-что я детектировал тут другого сказочника, который снапшотит базы данных и восстанавливает во всех случаях данные глупными блочными RAIDами. > данных на продакшне - это какбэ фигня, никто не заметит же, Так сабж как раз об этом. > особенно под хорошим грузом. Кэп намекает что сабж как раз для того и затеян. И да, ваши репорты давностью в квартал с вашим стабилизцом имеют околонулевую ценность когда вопрос о WIP. Если с того момента вышло 3-4 новых ядра - результаты тестирования на мегастабильном ядре (с бажным кодом btrfs) - вообще ни о чем.
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	74. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–2 +/–
	Сообщение от тигар (ok), 31-Мрт-14, 10:34
	>> Конечно, есть! Только вот один ма-а-аленький момент упустили из виду BtrFS - >> это вроде как клон zFS, > По возможностям - да. Более того - догнать и перегнать. Что они, > кстати, уже успешно делают. Например в btrfs можно местами отключить CoW, > если он мешается. А базам данных он как раз мешается. Ибо > не дружит с журнальной логикой. Журналить журналы - затея сомнительная, приводящая > к повторной работе на нескольких уровнях, это сажает производительность. Работа с диванный аналитег не имеет идей что с этим делать, статью на хабарахабар никто не написал по этой "проблеме"? подсказка: те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать, cow им не мешает при этом. > снапшотами гибче, экстенты есть, по поводу чего оно в бенчах обижало > ZFS даже когда пешком под стол ходило, управление кешом - интегрировано > с ядром, а не как в ZFS. "не как в zfs под линукс" имелось ввиду, я надеюсь? а где там, кстати, бенчи были, где оно обижало zfs ? >> Здесь нет наполеоновских планов, но набор фич заявлен серьёзный > Какой именно? Что там серьезного? Снапшоты? Бл! Там для них есть почти > все прямо сразу, сугубо за счет принципа работы. Было бы сранно > их НЕ заявлять при этом. >> и основной функционал _уже_ реализован, так что автор фс реально смотрит >> на вещи, в отличии от сказочников из оракла. > У сказочников из оракла уже работает большинство из фич, которые в tux3 > даже не рискуют заявлять.
	Ответить \| Правка \| К родителю #48 \| Наверх \| Cообщить модератору


	83. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	+/–
	Сообщение от Аноним (-), 31-Мрт-14, 19:42
	> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать, Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил здравый смысл. > cow им не мешает при этом. Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов такая мелочь не пугает. > "не как в zfs под линукс" имелось ввиду, я надеюсь? И под Linux, и под бзду. ARC везде одинаково не интегрирован с ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там конечно адаптируется, но если он сможет жрать большую часть памяти - программам попросившим большой блок памяти будет отлуп. А оно такое надо? Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным уже не айс. > а где там, кстати, бенчи были, где оно обижало zfs ? Да в куче мест. И на форониксе, и на еще куче ресурсов. Обижало оно даже в лохматом 2010 году, или когда там. С тех пор в btrfs впилили немеряно оптимизаций, если что.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	+/–
	Сообщение от тигар (ok), 01-Апр-14, 00:20
	>> те, кто пользуется zfs на хостах с DB уже давно знают что нужно делать, > Я тоже знаю: к доктору на прием записаться. Ибо фанатизм окончательно победил > здравый смысл. а где ты здесь фанатизм узрел? удобная в управлении fs. ей пользуются. >> cow им не мешает при этом. > Подумаешь, зажурналируем журнал и работа размножится в несколько раз. Настоящих фанатов > такая мелочь не пугает. "настоящие фанаты" знают как приготовить это дело так, чтобы не было "работа разможится". на хабарахабаре не пишут что нужно сделать? ну.. попробуй почитать оф. док-цию, например. >> "не как в zfs под линукс" имелось ввиду, я надеюсь? > И под Linux, и под бзду. ARC везде одинаково не интегрирован с > ядерным управлением памяти и живет своей жизнью IIRC. Он как-то там > конечно адаптируется, но если он сможет жрать большую часть памяти - > программам попросившим большой блок памяти будет отлуп. А оно такое надо? на википердии прочел? я вот своими глазами видел как мускл отожрал 70+гб памяти, до этого ее ела zfs. "под бзду", да. > Ну то-есть файлсерверам пофиг, там программ нет. А вот всем остальным > уже не айс. >> а где там, кстати, бенчи были, где оно обижало zfs ? > Да в куче мест. И на форониксе, и на еще куче ресурсов. > Обижало оно даже в лохматом 2010 году, или когда там. С > тех пор в btrfs впилили немеряно оптимизаций, если что. авторитетнее тестов похороникса, пожалуй, может быть только твое мнение. xD
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	–2 +/–
	Сообщение от Andrew Kolchoogin (ok), 31-Мрт-14, 12:41
	> Работа с снапшотами гибче, Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в ssh, который отресивить на другой машине и развернуть на другой BtrFS? > экстенты есть, по поводу чего оно в бенчах обижало ZFS даже когда пешком под стол ходило, И где же это оно его там обижало? > управление кешом - интегрировано с ядром, а не как в ZFS. Вы про какой кэш? Если про блочный -- то ШОА?! Если про ARC -- так это так и задумано.
	Ответить \| Правка \| К родителю #48 \| Наверх \| Cообщить модератору


	80. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	+/–
	Сообщение от А ты как думал (?), 31-Мрт-14, 19:28
	Конечно - https://btrfs.wiki.kernel.org/index.php/Main_Page#Features
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	+/–
	Сообщение от Аноним (-), 31-Мрт-14, 19:36
	> Поподробнее, пожалуйста. В BtrFS можно засендить снэпшот в стрим, который завернуть в > ssh, который отресивить на другой машине и развернуть на другой BtrFS? Если вы про send и receive - их в btrfs таки сделали. Такие вот чудеса науки. > И где же это оно его там обижало? Да даже на форониксе, как и в любых иных бенчах. Еще в 2010 году аж. А с тех пор нехило подтянули. > Если про ARC -- так это так и задумано. Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы с выдачей памяти - это так и задумано! Но устроит только файлсервер, где никаких программ нет. А в остальных местах обломы выделения памяти при попытке попросить блок пожирнее - как-то совсем не прикольно. Не хочу ничего сказать, но я бы не хотел видеть такую логику поведения на десктопе или сервере приложений.
	Ответить \| Правка \| К родителю #78 \| Наверх \| Cообщить модератору


	86. "Файловая система Tux3 вероятно будет добавлена в ядро Linux"	+/–
	Сообщение от тигар (ok), 01-Апр-14, 00:23
	> Да, конечно. Невозможность отжать у ФС кэш, даже когда пришлось обломать программы > с выдачей памяти - это так и задумано! Но устроит только > файлсервер, где никаких программ нет. А в остальных местах обломы выделения > памяти при попытке попросить блок пожирнее - как-то совсем не прикольно. > Не хочу ничего сказать, но я бы не хотел видеть такую > логику поведения на десктопе или сервере приложений. вот скажи, зачем ты свои влажные мечты изливаешь тут? кратко: ты написал не правду.
	Ответить \| Правка \| Наверх \| Cообщить модератору