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

Rad Hat развивает новую ФС NVFS для NVM-памяти, opennews (?), 18-Сен-20, (0) [смотреть все] Пфф, ещо чего не хватало Не дай Бог ламповые глюки ядра обойдут, а без них Linu, VINRARUS (ok), 23:21 , 18-Сен-20, (2) –22 // Ну как бы сложные ReFS и BTRFS так и не вышли из стадии игрушек , commiethebeastie (ok), 01:12 , 19-Сен-20, (19) –4 // Facebook использует Btrfs по полной программe плюс коммитит в ядро, но типически, сложные (?), 09:47 , 19-Сен-20, (54) +10 // да некоторые и петабайтные кластеры на refs уже понасобирали нет, не знаю, заче, пох. (?), 10:12 , 19-Сен-20, (58) –1 Фэйсбук может хоть фат12 использовать, там армия спецов есть и многа денег на эт, 98 (?), 11:31 , 19-Сен-20, (73) +4 и именно поэтому редхат внедряет бтрфс по дефолту в федоре ЛОЛ, у тебя логика, wefnwu (?), 14:38 , 19-Сен-20, (81) Именно поэтому Была бы не игрушкой - была бы в RHEL А пользователи федоры - оф, Аноним (93), 17:17 , 19-Сен-20, (93) +6 Но она по дефолту в SUSE, Nemton (?), 09:49 , 20-Сен-20, (112) +1 ну а на ком тестировать, на тех кто деньги заплатил btrfs они объявили deprecate, Аноним (103), 20:04 , 19-Сен-20, (103) Проверенно, месяца три назад, на только что отформатированный диск слил гигов 50, 98 (?), 11:35 , 20-Сен-20, (118) Смешные вы Мало ли что использует фейсбук Давайте теперь на пахе писать тогда, Дерьмократ (?), 10:08 , 14-Дек-20, (142) Подрывом пуканов - удовлетворен P S а вообще брали бы пример с г-на Комарова - , пох. (?), 10:10 , 19-Сен-20, (57) –1 // Ссылочку дайте , Аноним (-), 15:15 , 19-Сен-20, (82) // Subscribe by sending subscribe linux-fsdevel in the message body to majordomo vg, пох. (?), 16:24 , 19-Сен-20, (85) Что-то ты часто укоряешь других в поздем рождении А сам-то ты в каком веке роди, Аноним (88), 16:35 , 19-Сен-20, (88) +3 Нехватает пожатия на лету в lz4 , 79 (?), 23:28 , 18-Сен-20, (3) +5 // для таких хранилок лучше сжимать в zstd, ибо распаковка не будет замедлена но м, Аноним (5), 23:44 , 18-Сен-20, (5) +3 // Zstd топчик, на сильном сжатии он даже может обходить lzma без вопросов, но всё , Аноним (8), 23:55 , 18-Сен-20, (8) // процитирую себя мобильный ryzen 5 2500zstd --ultra -22 16 сек, xz -9, б.б. (?), 00:48 , 19-Сен-20, (15) Ну такое, да В прошлый раз, zstd был быстрее разница доходила до 15 , и файлы, Аноним (8), 01:42 , 19-Сен-20, (21) Распаковка в 8230 Ну у меня получилось в 5 раз быстрее, но вообще там очень ме, Аноним (8), 01:50 , 19-Сен-20, (22) zstd никогда не был быстрее lzma2, а уж тем более непрерывного архива rar5 zstd, Аноним (33), 05:39 , 19-Сен-20, (33) –3 Вы видимо анонимный эксперт, вам скорость или время , Аноним (5), 07:47 , 19-Сен-20, (41) +2 вы видимо админ локалхоста, попробуй сохрани в облаке пожатый архив размером в 1, Аноним (133), 09:00 , 21-Сен-20, (133) –1 а оно в мультипоточность умеет, или такое же как и gzip, однопоточное гв-но даж, Аноним (133), 09:04 , 21-Сен-20, (134) –1 А гонору-то, гонору сколько было рукалицо , Аноним (135), 12:50 , 21-Сен-20, (135) pigz и lbzip2 pbzip2 должно быть тоже быстро, Аноним (5), 04:09 , 19-Сен-20, (28) 1 У zstd упаковка адово тормозная на высоком сжатии 2 Степень сжатия сильно за, Аноним (93), 08:48 , 19-Сен-20, (43) Как насчет потребление ресурсов ЦПУ в многопотоке на SSD NVMe I O , Аноним (5), 12:41 , 19-Сен-20, (76) В EXT4 не смогли вкатить Подозреваю с NVFS ситуация будет аналогична , Аноним (9), 23:58 , 18-Сен-20, (9) +2 // Куда его там вкатывать и зачем По принципу по-файлового шифрования Я думаю, мо, Аноним (8), 00:00 , 19-Сен-20, (11) +1 там где-то катается vdo, со сжатием и дедупликацией, Аноним (103), 20:07 , 19-Сен-20, (104) // Если кратко очень медленно , Аноним (122), 13:39 , 20-Сен-20, (122) я и не говорил, что быстро, да и есть было не везде Зато не зависит от ФСподожд, Аноним (103), 18:37 , 20-Сен-20, (128) Жать данные с побайтовой спецыфикой доступа так же умно как хранение последнего , VINRARUS (ok), 00:07 , 19-Сен-20, (12) –2 // стильно, модно и молодежно Ведь так в винде а что платить при этом за nvmem , пох. (?), 10:15 , 19-Сен-20, (59) –2 // Эк, тебя понесло, уже индусов с ближним зарубежьем путаешь , Аноним (88), 16:40 , 19-Сен-20, (89) А может не надо лапшу на уши вешать , Аноним (4), 23:34 , 18-Сен-20, (4) –2 // Прояви гибкость и широту мышдения Абстрагируйся от подробностей работы flash-па, YetAnotherOnanym (ok), 07:33 , 19-Сен-20, (38) // А при чём тут флеш , Crazy Alex (ok), 09:05 , 19-Сен-20, (45) // Хмм действительно Казалось бы, при чём он здесь , YetAnotherOnanym (ok), 11:09 , 19-Сен-20, (71) +1 Ты свой нос в наш бизнес не суй, плз, спс, Чипмейкер (?), 17:22 , 19-Сен-20, (94) +1 // Ты мне не указывай куда нос совать или не совать, плз, спс , YetAnotherOnanym (ok), 18:42 , 19-Сен-20, (99) –3 Ну есть же Optane, Аноним (42), 07:50 , 19-Сен-20, (42) Речь не про M 2 NVMe, а про nvdimm Это обычные плашки оперативной памяти с возм, Аноним (49), 09:20 , 19-Сен-20, (49) +2 // угу, возможность сохранения же обеспечивается прямым подключением в ноосферу, а , пох. (?), 10:17 , 19-Сен-20, (60) // Там батейка стоит и её хватает, чтобы сохранить всю RAM в flash при внезапном от, Аноним (49), 10:21 , 19-Сен-20, (62) sure Потому что в верченных мной в руках модулях как-то не очень видно было мес, пох. (?), 10:32 , 19-Сен-20, (68) шуре Только там не батарейки, а ионисторы Отдельный флэш размером с весь модуль, Аноним (103), 20:51 , 19-Сен-20, (106) Ну вы в поисковике наберите nvdimm, там ж всё налицо, и флэш, и блок конденсатор, None (??), 11:02 , 19-Сен-20, (70) На уровне железа все пишется блоками в 64 байта cache line, ага , Аноним (131), 20:36 , 20-Сен-20, (131) На уровне железа все пишется и читается блоками в 64 байта cache line, ага , Аноним (131), 20:37 , 20-Сен-20, (132) Так вот в обычную память процессоры, имеющие кеш-память, и не пишет по байту Пи, n00by (ok), 10:29 , 19-Сен-20, (67) // Тем не менее, интерфейс позволяет читать и писать по одному байту , Annoynymous (ok), 16:00 , 19-Сен-20, (84) –3 Ребят, у них количество айнодов в фс задаётся при форматировании 2020 год не пер, лох (?), 23:48 , 18-Сен-20, (6) +5 // Нет нормальных алгоритмов, все файловые системы это помойка Btree тоже на свалк, Аноним (5), 23:49 , 18-Сен-20, (7) // Не помойка, а база данных , Аноним (14), 00:35 , 19-Сен-20, (14) +5 // https blocksandfiles com 2019 09 05 samsungs-potentially-groundbreaking-keyval, Аноним (5), 02:15 , 19-Сен-20, (25) Ну ext4 как-то живёт, какие проблемы Хм, сейчас посмотрел, на забитом диске 1 , Аноним (8), 23:58 , 18-Сен-20, (10) // Не скелиться если в одной папке много файлов, оно их физически выделяет в ОЗУ, Аноним (5), 02:03 , 19-Сен-20, (23) –3 // Используйте ZFS, кому нужны эти ретроградские ext4 и xfs , Тюринг (?), 02:04 , 19-Сен-20, (24) Лучше ext4, чем сын бсдшник , Бздуньк (?), 02:37 , 19-Сен-20, (27) +5 Нынче в бздю кладут реализацию с zfs on linux, а не то, что было ранее Так что д, Stanislavvv (?), 06:59 , 19-Сен-20, (36) Не сифилитик, а филателист, не бсдшник, а бдсмщик bsd-версия zfs нимодна, нимал, пох. (?), 10:19 , 19-Сен-20, (61) Лучше пи 769 дор на рее, чем акула в трюме 2 капитана-2 , PnD (??), 17:21 , 21-Сен-20, (137) а почему не HAMMER2 Серьёзно Жду развёрнутого ответа , Аноним (32), 05:24 , 19-Сен-20, (32) +2 Серьёзно Здесь ждешь , Аноним (140), 19:41 , 22-Сен-20, (140) +1 ECC RAM и материнку для неё и камень серверный уже купил , Аноним (93), 08:51 , 19-Сен-20, (44) –1 Других просто нету в стойках кроме ECC, Аноним (5), 09:10 , 19-Сен-20, (47) +1 Опять этот миф про необходимость ECC-памяти , Аноним (52), 09:44 , 19-Сен-20, (52) –1 Тебе скриншотик этого мифа из консоли показать Да, внезапно, энтерпрайзные ж, пох. (?), 10:22 , 19-Сен-20, (63) +2 ЕСС является желательной и в это плане zfs ничем не отличается от других файловы, Аноним (122), 10:54 , 19-Сен-20, (69) +2 Действительно, ведь бд сейчас обрабатывают данные сразу в фс без промежуточной з, Anonim1234 (?), 11:24 , 19-Сен-20, (72) А, ну в этом плане - да, не то чтоб сильно Но таки отличается в том моменте, что, пох. (?), 13:14 , 19-Сен-20, (78) Проблема была бы, если бы это количество нельзя было потом изменить , Annoynymous (ok), 00:51 , 19-Сен-20, (16) +3 // Переформатированием , Аноним (88), 16:51 , 19-Сен-20, (91) –1 Я, когда увидел эту фразу Aрхитектура NVFS близка к ФС Ext4 , тоже об этом под, Аноним (88), 16:46 , 19-Сен-20, (90) А сравнения btrfs где И с ntfs до кучи, Аноним Первый (?), 01:04 , 19-Сен-20, (18)   // btrfs труп, а ntfs онли винда, какие еще сравнения , Аноним (35), 06:33 , 19-Сен-20, (35) –3   // Откуда у вас такая информация , anonymous (??), 09:15 , 19-Сен-20, (48) –1   // Мое знакомство с ней закончилось после того, когда каждый запуск виндовой виртуа, Аноним (52), 09:51 , 19-Сен-20, (55)   Поздравляю со встречей с write amplification Хотя и странно, почему с zfs она у , пох. (?), 10:28 , 19-Сен-20, (66)   Проблема ведь не в том, что WA имеет место быть Проблем WA в непонятно каком ме, Аноним (122), 13:36 , 19-Сен-20, (80)   да в целом-то понятно, непонятно что с этим делать теперь АААА Вот где тебя кид, пох. (?), 16:33 , 19-Сен-20, (87)   Ошибаетесь, хотя при включенной компрессии действительно включается переменный р, Аноним (97), 18:34 , 19-Сен-20, (97)   Там размер записи 64k, во-первых, и нет, там все блоки переменной длины, не толь, пох. (?), 19:54 , 19-Сен-20, (101)   Файл с блоками в 1М был лишь примером Каким будет оптимальным размер блока для , Аноним (108), 01:17 , 20-Сен-20, (108)   _до_ первой мелкой операции записи в середину этого файла Что и есть основн, Аноним (115), 11:19 , 20-Сен-20, (115)   Да что я Вы можете в этом убедиться с помощью утилиты zdb , Аноним (108), 01:25 , 20-Сен-20, (110)   У BTRFS на большие файлы со случайным доступом на запись базы данных и образы в, Аноним (74), 11:36 , 19-Сен-20, (74) –1   Даже не знаю как это комментировать Прежде чем что-то написать - вы бы потрудил, Аноним (122), 13:08 , 19-Сен-20, (77) –1   Если человек не хочет, чтобы у него была активная запись на BTRFS по причине cop, Аноним (74), 21:44 , 19-Сен-20, (107) –1   Вам бы к врачу обратиться , Аноним (108), 01:21 , 20-Сен-20, (109) –1   Не читаете доки вы, а обратиться ко врачу надо мне , Аноним (74), 11:22 , 20-Сен-20, (116) +1   У вас проблемы с пониманием прочитанного Все что могу предложить ещё раз прочит, Аноним (122), 14:16 , 20-Сен-20, (123)   Вас не смущает что самый распространенный формат дисков виртуалок qCOW2 И он сд, Легивон (?), 09:52 , 20-Сен-20, (113)   Нет, не смущает В QCOW2 CoW используется только при наличии снапшотов образов , Аноним (74), 10:57 , 20-Сен-20, (114)   то ему надо наконец перестать в голову есть и включить мозг - как именно copy-on, Аноним (115), 11:28 , 20-Сен-20, (117) –1   Dataset вместо zvol был выбран вполне сознательно Разумеется были проведены все, Аноним (122), 13:12 , 20-Сен-20, (120)   А в чем именно заключались тесты и в чем отрыв -то И что лежит на fs - qemu овс, пох. (?), 19:31 , 20-Сен-20, (130)   Вполне может быть Как раз если очередь записи неглубокая - страницы в page cach, Аноним (121), 13:27 , 20-Сен-20, (121)   А пацаны из пейсбука и не знали , Аноним (50), 09:21 , 19-Сен-20, (50)   // Юзкейс пацанов из Фейсбука навряд ли совпадает с типовым , Аноним (52), 09:52 , 19-Сен-20, (56) +2   Ну и чем оно лучше bcachefs , Аноним (50), 01:14 , 19-Сен-20, (20) NVFS NTFSУ меня какие-то нездоровые аналогии РеДГад является тайным поклонник, Аноним (29), 05:14 , 19-Сен-20, (29) –6 так а зачем оно тогда вообще нужно Бред же, ну , Аноним (32), 05:22 , 19-Сен-20, (31) –1 // ну вдруг тебе этих данных не так чтоб и жалко тебе ж сказали - скопипащено с ext, пох. (?), 10:25 , 19-Сен-20, (64) // Ну да, FAT-то снапшоты поддерживает с первой версии , Annoynymous (ok), 18:36 , 19-Сен-20, (98) Да, давайте для каждого типа памяти наплодим кучу своих ФС, а затем забьем на ни, Аноним (37), 07:23 , 19-Сен-20, (37) // Ты ухватил самую суть современных создателей ФС , YetAnotherOnanym (ok), 07:44 , 19-Сен-20, (40) –1 Ну сюрприз - под байтовую адресацию нынешние ФС никто не делал Ты ж tar не пыта, Crazy Alex (ok), 09:08 , 19-Сен-20, (46) // пользователи mc недоумевают, почему Прекрасно ж работает Только вот к произвольн, пох. (?), 10:27 , 19-Сен-20, (65) Линуксоиды, сэр , Аноним (92), 17:05 , 19-Сен-20, (92) Исправьте название в канале, а то позор ведь , Аноним (39), 07:37 , 19-Сен-20, (39) Покойся с миром старая шляпа , Аноним (51), 09:34 , 19-Сен-20, (51) Ещё одна ФС В ядре уже 20 FS, лучше бы улучшали старые FS , Иваня (?), 09:44 , 19-Сен-20, (53) // существует 15 форматов - Надо сделать универсальный существует 16 форматов , Аноним (4), 15:56 , 19-Сен-20, (83) Надо просто ненужное старьё повыкидывать, вроде ReiserFS и JFS, Fracta1L (ok), 20:37 , 19-Сен-20, (105) // Я использую ReiserFS из-за её умения экономно хранить мелкие файлы , Аноним (88), 17:33 , 20-Сен-20, (126) +1 // Перестань её использовать, Fracta1L (ok), 18:49 , 20-Сен-20, (129) Сегодня суббота В линуксе есть ФС, позволяющая эффективно использовать субботу , EnemyOfDemocracy (?), 12:00 , 19-Сен-20, (75) // Если это предложение поучаствовать в разработке - где твой проект на гитхаб У м, пох. (?), 13:29 , 19-Сен-20, (79) +1 В Новогоднюю субботу Рош ха-Шана нельзя не то что в память что-то писать, но даж, Аноним (95), 17:24 , 19-Сен-20, (95) // Только правой рукой Носом или хером - пожалуйста , пох. (?), 17:31 , 19-Сен-20, (96) // Вы оба недопонимаете смысл Шаббата И правой рукой можно и носом и хером и гою з, Аноним (136), 14:13 , 21-Сен-20, (136) ШабатФС , Аноним (88), 17:35 , 20-Сен-20, (127) А они в курсе, что NVFS уже изобрели примерно в 2002-м https en wikipedia org, Annoynymous (ok), 18:43 , 19-Сен-20, (100) +2 // Лёня там постоянно что-то переизобретает и переписывает , Аноним (4), 18:13 , 22-Сен-20, (139) Когда уже сделают интерфейсы к samsung ssd для работы inline шифрование linux k, Аноним (5), 20:01 , 19-Сен-20, (102) Правильно ли я понимаю что UFS и FFS должны показывать отличные результаты на фл, Аноньимъ (?), 02:10 , 20-Сен-20, (111) // А они не показывают , Аноним (-), 15:05 , 20-Сен-20, (125) А как обстоит дело с выделением CO2 , аноним12345 (?), 16:47 , 22-Сен-20, (138) +1 Вот сейчас выйдет Рейзер он запилит РейзерФС и держитесь , Аноним (-), 09:28 , 25-Сен-20, (141) 2,3,4,6,18,20,29,31,37,39,51,53,75,100,102,111,138,141

Сообщения

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

18. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
Сообщение от Аноним Первый (?), 19-Сен-20, 01:04
А сравнения btrfs где? И с ntfs   до кучи
Ответить | Правка | Наверх | Cообщить модератору

	35. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–3 +/–
	Сообщение от Аноним (35), 19-Сен-20, 06:33
	btrfs труп, а ntfs онли винда, какие еще сравнения?
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–1 +/–
	Сообщение от anonymous (??), 19-Сен-20, 09:15
	> btrfs труп Откуда у вас такая информация?
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (52), 19-Сен-20, 09:51
	Мое знакомство с ней закончилось после того, когда каждый запуск виндовой виртуалки заканчивалось записью 2гб на ссд. Уж не знаю что с ней не так, но zfs пишет лишь сотню мегабайт при размере записи в 64к. Обе тестировались с компрессией.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от пох. (?), 19-Сен-20, 10:28
	Поздравляю со встречей с write amplification. Хотя и странно, почему с zfs она у тебя настолько мала.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (122), 19-Сен-20, 13:36
	Проблема ведь не в том, что WA имеет место быть. Проблем WA в непонятно каком месте и образом. Btrfs с компрессией записывает блоками по 128кб, а следовательно при сравнении с zfs с записью размером в 64кб WA должно быть ровно в 2 раза выше, но по факту - на порядок выше. И это просто запуск виртуалки с виндой и завершение ее работы, и больше ничего.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от пох. (?), 19-Сен-20, 16:33
	> Проблема ведь не в том, что WA имеет место быть. Проблем WA в непонятно каком месте и образом. да в целом-то понятно, непонятно что с этим делать теперь. > а следовательно при сравнении с zfs с записью размером в 64кб WA АААА! Вот где тебя кидают, надо было мне сразу сообразить. У тебя ж zfs тоже с компрессией и compressed arc до кучи, ты ж не отключал ничего руками? Ну так вот и поздравляю: при этом используется _переменный_ recordsize, а те твои 64 - это ограничение сверху.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (97), 19-Сен-20, 18:34
	Ошибаетесь, хотя при включенной компрессии действительно включается переменный размер записи, но так как образ - это один большой файл, то и пишется от максимальным размером. Файл 256М в уже  упакованном виде при размере записи в 1М будет иметь 256 блока и любое изменение даже одного бай приведет к полной перезаписи этого 1М блока . О переменном размере блока речи уже не идет - файл размером с запись или выше уже записывается блоком максимального размера.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от пох. (?), 19-Сен-20, 19:54
	> в уже  упакованном виде при размере записи в 1М будет иметь 256 блока Там размер записи 64k, во-первых, и нет, там все блоки переменной длины, не только у коротких файлов. Подумайте что происходит при попытке записи в середину пакованного файла из одних нулей килобайта из /dev/random. И наоборот. Собственно, именно из-за этого и пришлось вводить блоки переменной длинны, а не ради возможности сэкономить три копейки на сверхкоротких файлах. А вот btrfs, по всей видимости, может в этом случае только из одного блока сделать два, ибо нивлызло. Записали мы килобайт, на диск записалось 2x128, вот это красота, 256x write amplification на ровном месте. (все, естественно, чисто умозрительно, я не знаю как она на самом деле устроена. Но имеющиеся чудеса объявняет довольно правдоподобно. Кстати, легко проверяемо автором.)
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (108), 20-Сен-20, 01:17
	Файл с блоками в 1М был лишь примером. Каким будет оптимальным размер блока для одного большого файла? Разумеется максимальный. Вот откуда возникается WA и почему для образов виртуальных машин рек.размер записи как можно ближе к 4К.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (115), 20-Сен-20, 11:19
	> Файл с блоками в 1М был лишь примером. Каким будет оптимальным размер блока для одного большого > файла? _до_ первой мелкой (!) операции записи в середину этого файла. Что и есть основной процесс, происходящий когда этот файл - виртуальный диск. После чего с переменным размером блока мы перезапишем пострадавший блок и небольшой непоместившийся туда хвост отдельным мелким блоком (для простоты опустим чего и сколько помимо того придется писать), а с постоянным - два блока полного размера 128k, второй из которых при этом будет почти пустым, но еще и при чтении будет нам префетч загаживать ненужными нулями. > для образов виртуальных машин рек.размер записи как можно ближе к 4К. видимо, для btrfs это действительно лучший выбор. И еще хорошо бы внутри vm попасть границами разделов на эти 4k, а не мимо. cow, кстати, как какие-то дятлы насоветовали, выключать не надо, совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (108), 20-Сен-20, 01:25
	Да что я. Вы можете в этом убедиться с помощью утилиты zdb!
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	74. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–1 +/–
	Сообщение от Аноним (74), 19-Сен-20, 11:36
	У BTRFS на большие файлы со случайным доступом на запись (базы данных и образы виртуалок) надо ставить атрибут nodatacow, как раз, чтобы твоей проблемы не было. Если бы ты хоть чуть-чуть ознакомился с документацией на ФС, которой пользуешься - у тебя бы не возникло таких вопросов. BTRFS по дефолту делает copy-on-write, поэтому на мелкие записи он не пишет в тот же блок, а создаёт новый модифицированный и меняет поинтер. Отсюда write amplification. Очевидно, это не желательно на образах ВМок, поэтому можно попросить ФС писать данные in-place. Во всех гайдах по BTRFS есть инфа, что на образы виртуалок надо ставить nodatacow.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	77. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–1 +/–
	Сообщение от Аноним (122), 19-Сен-20, 13:08
	Даже не знаю как это комментировать. Прежде чем что-то написать - вы бы потрудились вникнуть в прочитанное. Неловкая ситуация получилась.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–1 +/–
	Сообщение от Аноним (74), 19-Сен-20, 21:44
	Если человек не хочет, чтобы у него была активная запись на BTRFS по причине copy-on-write может этот самый copy-on-write отключить для файлика, где это вызывает у него проблемы. Если человек не хочет отключать copy-on-write для этого файлика, но при этом ноет, что ФС плохая - то у меня для него плохие новости - это уже забагованность его генетического кода. БД и виртуальные диски слишком большие и у них слишком случайные паттерны доступа, поэтому они плохо вписываются в механизм работы CoW. И не так сложно сделать `chattr +C` и отключить CoW на пару-тройку файлов, где это реально мешает (а пользы от CoW в целом так-то больше, если, конечно, на томе лежат не только имиджи виртуалок). Это не проблема файловой системы. Просто нужно знать сильные и слабые стороны ФС, с которой работаешь. Тем более, что ФС умеет хорошо работать с нагрузками такого типа, нужно просто дёрнуть за нужную ручку. Если это слишком сложно - то да, таким людям лучше просто не пользоваться BTRFS, т.к. это слишком сложная ФС, которая находится за гранью их интеллектуальных способностей. Если же у вас только образы виртуалок на BTRFS лежат - то это ещё более странная претензия к ФС. Ибо для вас и микроскоп будет слишком плохим молотком. Каждой задаче - свой инструмент. И либо отводите какой-нибудь ext4/XFS под виртуалки, либо проставляйте правильно атрибуты на BTRFS.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–1 +/–
	Сообщение от Аноним (108), 20-Сен-20, 01:21
	Вам бы к врачу обратиться.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+1 +/–
	Сообщение от Аноним (74), 20-Сен-20, 11:22
	Не читаете доки вы, а обратиться ко врачу надо мне?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (122), 20-Сен-20, 14:16
	У вас проблемы с пониманием прочитанного. Все что могу предложить ещё раз прочитать и попытаться вникнуть в суть или обратиться к врачу.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Легивон (?), 20-Сен-20, 09:52
	Вас не смущает что самый распространенный формат дисков виртуалок qCOW2? И он сделает то же самое, только уровнем выше. Его тоже отключать? Имхо главное чтобы COW не работал дважды, а где его отключать не так важно. Но я бы конечно на уровне настройки приложения отключал (и отключаю), тоесть у qcow2.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	114. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (74), 20-Сен-20, 10:57
	Нет, не смущает. В QCOW2 CoW используется только при наличии снапшотов образов. Если вы не пользуетесь снапшотами ВМок - то у вас и так нет copy-on-write в образах ВМки. Запись в QCOW2 идёт in-place, а CoW происходит исключительно если у вас есть read-only снапшот и гипервизор пытается записать в read-only блок. При этом исходный блок копируется и копия становится read/write. Если вы "отключаете" CoW в QCOW2 - значит вы снапшотами не пользуетесь и всё равно у вас бы не было CoW на уровне приложения. В случае с BTRFS по умолчанию всегда происходит copy-on-write блока, вне зависимости от того, есть ли снапшоты у данного файла или нет. Это by-design заложено в архитектуре ФС. Я не предлагаю отключать глобально на всей ФС CoW, это действительно плохо (хотя и можно), но вполне можно помочь файловой системе и себе и поставить атрибут +C на имиджи виртуалок.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	–1 +/–
	Сообщение от Аноним (115), 20-Сен-20, 11:28
	> Если человек не хочет, чтобы у него была активная запись на BTRFS по причине copy-on-write то ему надо наконец перестать в голову есть и включить мозг - как именно copy-on-write может вызвать 256x write amplification. И быстренько сообразить, что он тут не то что не причем, а еще и вполне может улучшить жизнь если на fs включена компрессия. "На старое место" у вас _все_равно_ не влезет. > Каждой задаче - свой инструмент. а btrfs инструмент ни для какой задачи, так и запишем. > И либо отводите какой-нибудь ext4/XFS под виртуалки, либо просто не пользуйтесь недоделком. У человека с zfs нет никакой проблемы, при том что там, о ужас, ужас - страшный _неотключаемый_ CoW. А если еще он и zvol осилит, вместо бессмысленных для этой цели файлов...
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	120. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (122), 20-Сен-20, 13:12
	Dataset вместо zvol был выбран вполне сознательно. Разумеется были проведены все необходимые тесты и dataset победил с завидным отрывом.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от пох. (?), 20-Сен-20, 19:31
	А в чем именно заключались тесты и в чем 'отрыв'-то? И что лежит на fs - qemu'овский qcow2 ?
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (121), 20-Сен-20, 13:27
	Вполне может быть. Как раз если очередь записи неглубокая - страницы в page cache не задерживаются, и на каждые пару байт записи коммитится целый блок, который сразу же пишется на диск. И в итоге, вместо одной записи блока будут десятки CoW записей. Тут, конечно, проблема комплексная, надо разбираться, явно где-то кэширование неправильно работает. В госте, в гипервизоре или на хосте. Я не говорил, что CoW тут единственная проблема, но отключение его для образов виртуалки должно было существенно уменьшить write amplification. А дальше нужно уже искать, где у вас корявые кэши.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	50. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+/–
	Сообщение от Аноним (50), 19-Сен-20, 09:21
	А пацаны из пейсбука и не знали.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	56. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"	+2 +/–
	Сообщение от Аноним (52), 19-Сен-20, 09:52
	Юзкейс пацанов из Фейсбука навряд ли совпадает с типовым.
	Ответить | Правка | Наверх | Cообщить модератору

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

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