The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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


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

Оглавление

Релиз Red Hat Enterprise Linux 7, opennews (??), 10-Июн-14, (0) [смотреть все]

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


94. "Увидел свет дистрибутив Red Hat Enterprise Linux 7"  +1 +/–
Сообщение от linux must _RIP__ (?), 11-Июн-14, 10:53 
теоритический размер. практический (и тестированый) ограничен 64ТБ. Недавно смогли протестировать и подтвердить работоспособность на 128ТБ (попутно поправив стопку багов связаных с размерами типов). Теперь вот предстоит проверять на 246ТБ - опять стопку багов прийдется фиксить и ускорять тормозные операции.
Ответить | Правка | Наверх | Cообщить модератору

121. "Увидел свет дистрибутив Red Hat Enterprise Linux 7"  +/–
Сообщение от Michael Shigorinemail (ok), 11-Июн-14, 13:33 
И на том спасибо.
Ответить | Правка | Наверх | Cообщить модератору

127. "Увидел свет дистрибутив Red Hat Enterprise Linux 7"  +/–
Сообщение от linux must _RIP__ (?), 11-Июн-14, 14:25 
а за нахождения бага в linux mm LRU спасибо скажете? :) до 3.10/3.15 был забавный баг - когда страницы только прочитаные с диска попадали в временный pagevec и оттуда вымывались в первую очередь в случае не хватки памяти. Особенно было забавно это наблюдать на ext4 metadata - когда пишем в файл, тут же забываем информацию о битмапах и повторно читаем с диска :-) скорость падала в разы. простой фикс занимал ровно 2 строки, вошедший в ядро - лопатил lru как бог черепаху.
Ответить | Правка | Наверх | Cообщить модератору

140. "Увидел свет дистрибутив Red Hat Enterprise Linux 7"  –1 +/–
Сообщение от iZEN (ok), 11-Июн-14, 19:38 
А теперь такое же проверьте на UFS2 во FreeBSD, если не трудно.
Ответить | Правка | Наверх | Cообщить модератору

147. "Увидел свет дистрибутив Red Hat Enterprise Linux 7"  +/–
Сообщение от linux must _RIP__ (?), 11-Июн-14, 22:34 
> А теперь такое же проверьте на UFS2 во FreeBSD, если не трудно.

в freebsd vm такой баг не возможен в принципе, там другая архитектура LRU кэша страниц. это только в linux могли придумать игнорировать активацию страниц в сязи с тем что она слишком ранная и устраивать задержку в добавлении в LRU пока не наберется 14 страниц per CPU - что дает 14 * 4kb * 512 = несколько мегабайт памяти пролетающей мимо LRU кэша;

Это так "оптимизировали" LRU локинг. Хотя один хрен чуть что вызывают lru_add_drain для перемещения в нормальный LRU. как собственно и исправили для ext3/4.

Отдельный прикол о том что служебную иноду забыли пометить как I_NEW что флушит ее при первом же чихе.


Index: linux-stage/fs/ext4/mballoc.c
===================================================================
--- linux-stage.orig/fs/ext4/mballoc.c
+++ linux-stage/fs/ext4/mballoc.c
@@ -26,6 +26,7 @@
#include <linux/debugfs.h>
#include <linux/vmalloc.h>
#include <trace/events/ext4.h>
+#include <linux/swap.h>

/*
  * MUSTDO:
@@ -943,8 +944,11 @@ static int ext4_mb_init_cache(struct pag
            incore = data;
        }
    }
-    if (likely(err == 0))
+    if (likely(err == 0)) {
        SetPageUptodate(page);
+        /* make sure it's in active list */
+        mark_page_accessed(page);
+    }

out:
    if (bh) {
@@ -1050,6 +1054,7 @@ int ext4_mb_init_group(struct super_bloc
    }

    page = e4b.bd_bitmap_page;
+    lru_add_drain();
    ret = ext4_mb_init_cache(page, NULL);
    if (ret)
        goto err;
@@ -1070,6 +1075,7 @@ int ext4_mb_init_group(struct super_bloc
    }
    /* init buddy cache */
    page = e4b.bd_buddy_page;
+    lru_add_drain();
    ret = ext4_mb_init_cache(page, e4b.bd_bitmap);
    if (ret)
        goto err;
@@ -1151,6 +1157,7 @@ ext4_mb_load_buddy(struct super_block *s
        if (page) {
            BUG_ON(page->mapping != inode->i_mapping);
            if (!PageUptodate(page)) {
+                lru_add_drain();
                ret = ext4_mb_init_cache(page, NULL);
                if (ret) {
                    unlock_page(page);
@@ -1182,6 +1189,7 @@ ext4_mb_load_buddy(struct super_block *s
        if (page) {
            BUG_ON(page->mapping != inode->i_mapping);
            if (!PageUptodate(page)) {
+                lru_add_drain();
                ret = ext4_mb_init_cache(page, e4b->bd_bitmap);
                if (ret) {
                    unlock_page(page);
@@ -2483,6 +2491,7 @@ static int ext4_mb_init_backend(struct s
     * not in the inode hash, so it should never be found by iget(), but
     * this will avoid confusion if it ever shows up during debugging. */
    sbi->s_buddy_cache->i_ino = EXT4_BAD_INO;
+    sbi->s_buddy_cache->i_state = I_NEW;
    EXT4_I(sbi->s_buddy_cache)->i_disksize = 0;
    for (i = 0; i < ngroups; i++) {
        desc = ext4_get_group_desc(sb, i, NULL);
@@ -2711,6 +2720,7 @@ int ext4_mb_release(struct super_block *
    }
    kfree(sbi->s_mb_offsets);
    kfree(sbi->s_mb_maxs);
+    sbi->s_buddy_cache->i_state = 0;
    if (sbi->s_buddy_cache)
        iput(sbi->s_buddy_cache);
    if (sbi->s_mb_stats) {

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

160. "Увидел свет дистрибутив Red Hat Enterprise Linux 7"  +1 +/–
Сообщение от Аноним (-), 12-Июн-14, 07:28 
> А теперь такое же проверьте на UFS2 во FreeBSD, если не трудно.

А этого только могила исправит. Он эпик фэйл еще на уровне дисковых структур оставшихся чуть менее чем полностью из антикварного UFS-а, проектированного при царе горохе. При этом все остальное уже не важно.

И да, что-то у меня есть сомнения что линуксхрипу кто-то готов оплачивать подобную активность для бзды.


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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру