abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 0
včera 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 12
včera 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 2
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 963 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Moje zkušenosti s bcache

    18.2.2015 21:40 | Přečteno: 1783× | Výběrový blog | poslední úprava: 18.2.2015 21:45

    V diskusi pod článkem GlusterFS 3.6 a pár blbostí kolem mi Aleš Kapica doporučil, abych sepsal svoje poznatky ohledně dm-cache ve writeback režimu. Nakonec jsem po testech dospěl pouze ke konstatování, že ve writeback režimu je dm-cache na dvě věci a že to už přede mnou zjistili i jiní, nicméně řekl jsem si, že bych mohl sepsat nějaké své zkušenosti s provozem alternativy v podobě bcache.

    Takže bcache stejně jako dm-cache (nebo Flashcache od Facebooku) umí použít SSD jako vyrovnávací paměť pro čtení či zápis (obvykle) z rotačních disků. Popis jak se nastavuje najdete například zde, nemá cenu, abych ho znovu sepisoval.

    Sám bcache používám jen na jednom serveru, kde mi zrychluje přístup k disku pro KVM virtuál s Windows 2012 R2 a Kerio Connectem. Kerio má při hromadných změnách většího množství zpráv (např. při mazání celých složek apod.) poměrně velké nároky na náhodný přístup k disku a zapojení bcache ve writeback režimu je skutečně znát. Jako operační systém nad fyzickým železem použivám Gentoo Linux neboť v tomto případě potřebuji rozumně nové verze software, ale zároveň i dostatečnou stabilitu a možnost vrátit se v případě problémů ke starším verzím. Gentoo mi nabízí dostatečný kompromis mezi tím vším. Mám v něm k dispozici i více verzí jader, takže mohu zůstávat u jádra ve verzi 3.12, která - narozdíl od vyšších verzí až po současnou 3.19 - netrpí regresemi (viz níže).

    Init skript

    Protože mi v Gentoo nefunguje detekce cachovaného zařízení umístěného na LVM pomocí udev, zbastlil jsem si následující init skript pro OpenRC:
    #!/sbin/runscript
    
    extra_started_commands="disable_cache"
    
    TEMPFILE="$(mktemp)"
    trap "do_clean" EXIT
    
    depend() {
        use dmeventd
        before checkfs fsck
        after dmeventd modules device-mapper lvm localmount
    }
    
    do_clean() {
        [ -f "${TEMPFILE}" ] && rm -f "${TEMPFILE}"
    }
    
    get_uuid() {
    
        local dev="${1}"
        if [ ! -e "${dev}" ]; then
            eerror "Nebylo urceno platne blokove zarizeni."
            return 1
        fi
        # Zjisteni UUID zarizeni
        /sbin/bcache-super-show "${dev}" | grep dev.uuid | awk '{print $2}' > "${TEMPFILE}"
        x="${?}"
        [ "${x}" != "0" ] && return "${x}"
        local uuid="$(cat ${TEMPFILE})"
        if [ -z "${uuid}" ]; then
            eerror "Nepodarilo se nacist ID zarizeni."
            return 1
        fi
    
        # Zjisteni UUID bcache
        /sbin/bcache-super-show "${dev}" | grep cset.uuid | awk '{print $2}' > "${TEMPFILE}"
        x="${?}"
        [ "${x}" != "0" ] && return "${x}"
        local cset="$(cat ${TEMPFILE})"
        if [ -z "${cset}" ]; then
            eerror "Nepodarilo se nacist ID bcache."
            return 1
        fi
    
        # Nacteni typu zarizeni (zalohovane nebo cache)
        /sbin/bcache-super-show "${dev}" | grep sb.version | awk '{print $2}' > "${TEMPFILE}"
        x="${?}"
        [ "${x}" != "0" ] && return "${x}"
        local sbver="$(cat ${TEMPFILE})"
        if [ -z "${sbver}" ]; then
            eerror "Nepodarilo se nacist typ zarizeni ${dev}."
            return 1
        fi
    
    
        # Test, jestli nejde o detachovane zarizeni
        if [ "${sbver}" == "1" ]; then
            /sbin/bcache-super-show "${dev}" | grep dev.data.cache_state | awk '{print $2}' > "${TEMPFILE}"
            x="${?}"
            [ "${x}" != "0" ] && return "${x}"
    
            local state="$(cat ${TEMPFILE})"
            if [ -z "${state}" ]; then
                eerror "Nepodarilo se nacist status zalohovaneho zarizeni."
                return 1
            fi
        fi
    
        UUID=${uuid}
        CSET=${cset}
        DETACHED=0
    
        [ "${sbver}" == "1" ] && [ "${state}" == "0" ] && DETACHED=1
        return 0
    
    }
    
    get_dev() {
    
        local dev="${1}"
    
        lsblk -o NAME -i "${1}" -n -p -l | egrep '/dev/bcache[0-9]+' > "${TEMPFILE}"
        x="${?}"
        [ "${x}" != "0" ] && return "${x}"
    
        local devname="$(cat ${TEMPFILE})"
        [ -z "${devname}" ] && return 1
    
        local devname="${devname##*/}"
        DEVNAME="${devname}"
    
        return 0
    
    }
    
    
    do_start() {
    
        local dev="${1}"
        local cache_dev="${2}"
        local mode="${3}"
    
        get_dev "${dev}"
        x=${?}
        [ "${x}" != "0" ] && echo "${dev}" > /sys/fs/bcache/register
    
    
        get_uuid "${dev}"
        x="${?}"; [ "${x}" != "0" ] && return "${x}"
        local dev_uuid="${UUID}"
        local cset="${CSET}"
        local detached="${DETACHED}"
    
    
        get_dev "${dev}" "${cset}"
        x="${?}"; [ "${x}" != "0" ] && return "${x}"
        local devname="${DEVNAME}"
    
        if [ "${cache_dev}" != "none" ]; then
    
            get_uuid "${cache_dev}"
            [ ! -d "/sys/fs/bcache/${CSET}" ] && echo "${cache_dev}" > /sys/fs/bcache/register
            get_uuid "${cache_dev}"
            x="${?}"; [ "${x}" != "0" ] && return "${x}"
            local cache_uuid="${UUID}"
            if [ "${detached}" != "1" ] && [ "${cset}" != "00000000-0000-0000-0000-000000000000" ] ; then
                if [ "${cset}" != "${CSET}" ]; then
                    eerror "Zarizeni nejsou sparovana:"
                    eerror "   ${dev}"
                    eerror "   ${cache_dev}"
                    return 1
                fi
            else
                echo ${CSET} > /sys/block/${DEVNAME}/bcache/attach
            fi
        fi
    
        # Zmena rezimu cachovani
        [ -n "${mode}" ] && echo "${mode}" > /sys/block/${devname}/bcache/cache_mode
    
        return 0
    
    }
    
    do_stop() {
    
        local dev="${1}"
        local cache_dev="${2}"
    
        get_uuid "${dev}"
        x="${?}"; [ "${x}" != "0" ] && return "${x}"
        local cset="${CSET}"
    
        get_dev "${dev}"
        x="${?}"; [ "${x}" != "0" ] && return "${x}"
        local devname="${DEVNAME}"
    
       if [ -d /sys/block/${devname}/bcache/ ]; then
            echo 1 > /sys/block/${devname}/bcache/stop
            x="${?}"; [ "${x}" != "0" ] && return "${x}"
        fi
        return 0
    
    }
    
    start() {
    
        ebegin "Nahazuji bcache:"
    
        DEVCNT=${#bkdev[@]}
        if [ "${DEVCNT}" != "${#cachedev[@]}" ]; then
            eerror "Chyba: nesouhlasi pocet zalohujicich a zalohovanych zarizeni"
            eend 1
            return 1
        fi
    
        local scs=1
        for(( i=0; i<${DEVCNT}; i++ )); do
            local bd="${bkdev[$i]}"
            local cd="${cachedev[$i]}"
            local mode="${mode[$i]}"
            einfo "Nahazuji zalohovane rozhrani '${bd}'."
            do_start "${bd}" "${cd}" "${mode}"
            if [ "$?" != "0" ]; then
                ewarn "Pri nahazovani nekde nastala chyba."
            else
                local scs=0
            fi
        done
    
        eend ${scs}
    
    }
    
    stop() {
    
        ebegin "Shazuji bcache:"
    
        local scs=1
        DEVCNT=${#bkdev[@]}
        for(( i=0; i<${DEVCNT}; i++ )); do
            local bd="${bkdev[$i]}"
            local cd="${cachedev[$i]}"
            einfo "Shazuji zalohovane rozhrani '${bd}'."
            do_stop "${bd}" "${cd}"
            if [ "$?" != "0" ]; then
                ewarn "Pri shazovani nekde nastala chyba."
            else
                local scs=0
            fi
        done
    
        eend ${scs}
    
    }
    
    disable_cache() {
    
        ebegin "Vypinam cachovani u bcache"
    
        local scs=0
        DEVCNT=${#bkdev[@]}
        for(( i=0; i<${DEVCNT}; i++ )); do
            local bd="${bkdev[$i]}"
            einfo "Vypinam cachovani u '${bd}'."
            get_dev "${bd}"
            x="${?}"; [ "${x}" != "0" ] && ewarn "Pri zmene nastaveni nekde nastala chyba."
            local devname="${DEVNAME}"
            echo none > /sys/block/${devname}/bcache/cache_mode
        done
    
        eend ${scs}
    
    }
    
    Skript používá konfigurační soubor /etc/conf.d/bcache, v mém případě je jeho obsah následující:
    bkdev=(/dev/vg/kvm.kerio-disk1)
    cachedev=(/dev/md10)
    mode=(writeback)
    
    Pokud máte více cachovaných disků, je možné do závorek zapsat více blokových zařízení (a módů) oddělených mezerou.

    Oprava mazání obsahu /dev/bcache udevem

    Cachovaný disk se v /dev ukazuje pod názvem /dev/bcacheX, kde X je číslo od nuly výš. Bohužel toto číslo není jednoznačné. Pokud cache vypnu a zase zapnu, dostanu /dev/bcache1 místo /dev/bcache0, zrovna tak pokud cachované disky detekuje udev a je jich víc, není nikde zajištěno, že při příštím startu bude pořadí jejich nalezení stejné. Proto je praktičtější použít symlink /dev/bcache/by-uuid/<uuid>, který udev vytváří automaticky v okamžiku, kdy si všimne nového blokového zařízení naformátovaného pro bcache. Aby to ale nebylo tak jednoduché, tak mi po každém vypnutí KVM virtuálu běžícího nad cachovaným diskem (a vlastně i po jakémkoli spuštění 'udevadm trigger') udev celý obsah /dev/bcache zase smaže. Protože se mi nepodařilo zjistit, kde přesně k té chybě dochází, dospěl jsem k závěru, že bude lepší před novým startem potřebný symlink prostě explicitně vytvořit. QEMU si startuji vlastními skripty a tak nebyl problém udělat si potřebnou úpravu.

    Následující skript tedy spouštím před startem KVM virtuálu. Hodnoty PRE_START_CSET a PRE_START_UUID vyčtete z výstupu 'bcache-super-show /dev/cachovane/zarizeni', jedná se o řádky 'cset.uuid' a 'dev.uuid' v uvedeném pořadí. Zároveň mi skript i zmenšuje hodnotu hranice pro detekci sekvenčního zápisu v souboru '/sys/block/${devname}/bcache/sequential_cutoff' na 64kB - sekvenční zápisy nad tuto velikost jsou potom zapisovány přímo na rotační disk, čímž se snižuje opotřebení SSD. 64kB pro potřeby Keria v mém nasazení v pohodě stačí, výchozí 4MB jsou v tomto případě zbytečné.
    #!/bin/bash
    
    # Oprava chyby, pri ktere udev po ukonceni KVM (nebo proste jen po udevadm trigger)
    # smaze cely obsah /dev/bcache
    
    PRE_START_CSET=e2dc102d-9b5c-4e22-b2c4-b6576479f7c7
    PRE_START_UUID=c64c2da1-5e83-43e0-b042-0a7f468396c4
    PRE_START_TEMPFILE="$(mktemp)"
    PRE_START_TMPVAR=""
    
    pre_start_clear() {
        [ -f "${PRE_START_TEMPFILE}" ] && rm -f "${PRE_START_TEMPFILE}"
    }
    
    pre_start_check_dev() {
    
        local dev="${1}"
        [ ! -L "${dev}/dev" ] && return 1
    
        while read pre_start_bc_slave_dev; do
    
            /usr/bin/readlink -f "${pre_start_bc_slave_dev}" > "${PRE_START_TEMPFILE}"
            local x="${?}"
            [ "${x}" != "0" ] && return "${x}"
    
            local devname="$(cat ${PRE_START_TEMPFILE})"
            local devname="${devname##*/}"
    
            [ -n "$(/sbin/bcache-super-show /dev/${devname} 2>&1 | grep -i ${PRE_START_UUID})" ] \
                && return 0
    
        done < <(find "${dev}/dev/slaves" -maxdepth 1 -type l )
    
        return 1
    
    }
    
    pre_start_update_bcache() {
    
        local bdev=
        for pre_start_x in /sys/fs/bcache/${PRE_START_CSET}/bdev*; do
            pre_start_check_dev "${pre_start_x}"
            if [ "$?" == "0" ]; then
                local bdev="${pre_start_x}"
                break
            fi
        done
    
        [ -z "${bdev}" ] && return 1
        /usr/bin/readlink -f "${pre_start_x}/dev" > "${PRE_START_TEMPFILE}"
        local x="${?}"
        [ "${x}" != "0" ] && return "${x}"
        local devname="$(cat ${PRE_START_TEMPFILE})"
        local devname="${devname##*/}"
    
        echo 64k > /sys/block/${devname}/bcache/sequential_cutoff
        [ -d /dev/bcache/by-uuid ] && [ -e /dev/bcache/by-uuid/${PRE_START_UUID} ] && return 0
    
    
        [ ! -d /dev/bcache ] && mkdir /dev/bcache
        [ ! -d /dev/bcache/by-uuid ] && mkdir /dev/bcache/by-uuid
        ln -s "../../${devname}" /dev/bcache/by-uuid/${PRE_START_UUID}
    
    }
    
    pre_start_update_bcache
    pre_start_clear
    

    Regrese

    V podstatě až do vánočních svátků jsem na popisovaném stroji jel nad jádrem 3.12. Na druhý svátek vánoční jsem se rozhodl nadělit serveru novější jádro a upgradoval jsem na gentoo-sources-3.17.x (tuším že 3.17.8). Po restartu jsem si všiml zvýšeného loadu, ale rychlý benchmark neukazoval na nějaký snížený výkon a tak jsem řešení nechal na ráno a šel spát.

    Ráno mě bohužel čekalo nepříjemné překvapení v podobě hlášení od Zabbixe o nedostupnosti portů Kerio Connectu. Virtualizované Windows sice jely, ale pokusy o přístup na disk vyhrazený pro data mailserveru byly neúspěšné a na fyzickém stroji mi dmesg vypisoval nějaké takovéhle nadávky:
    [ 2138.360002] INFO: rcu_sched self-detected stall on CPU { 0}  (t=21000 jiffies g=23827 c=23826 q=2794)
    [ 2138.360002] Task dump for CPU 0:
    [ 2138.360002] bcache_gc       R  running task        0  3010      2 0x00080008
    [ 2138.360002]  0000000000000001 ffffffff81877100 ffffffff81113abf 0000000000005d13
    [ 2138.360002]  ffff880272411d80 ffffffff81877100 ffffffff81877100 ffffffff818bbb08
    [ 2138.360002]  ffffffff81116c68 001dcd6500000000 ffff880272411140 0000000000000096
    [ 2138.360002] Call Trace:
    [ 2138.360002]  <IRQ>  [<ffffffff81113abf>] ? rcu_dump_cpu_stacks+0x7f/0xc0
    [ 2138.360002]  [<ffffffff81116c68>] ? rcu_check_callbacks+0x368/0x5a0
    [ 2138.360002]  [<ffffffff81127050>] ? tick_sched_handle.isra.18+0x30/0x30
    [ 2138.360002]  [<ffffffff811190b1>] ? update_process_times+0x31/0x60
    [ 2138.360002]  [<ffffffff81127050>] ? tick_sched_handle.isra.18+0x30/0x30
    [ 2138.360002]  [<ffffffff81127083>] ? tick_sched_timer+0x33/0x60
    [ 2138.360002]  [<ffffffff81119695>] ? __run_hrtimer.isra.34+0x45/0xc0
    [ 2138.360002]  [<ffffffff81119c67>] ? hrtimer_interrupt+0xd7/0x230
    [ 2138.360002]  [<ffffffff8102e6f5>] ? smp_apic_timer_interrupt+0x35/0x50
    [ 2138.360002]  [<ffffffff816622bd>] ? apic_timer_interrupt+0x6d/0x80
    [ 2138.360002]  <EOI>  [>ffffffff81523ea5>] ? bch_extent_bad+0xf5/0x1b0
    [ 2138.360002]  [<ffffffff81523ddc>] ? bch_extent_bad+0x2c/0x1b0
    [ 2138.360002]  [<ffffffff8151c2b0>] ? bch_ptr_invalid+0x10/0x10
    [ 2138.360002]  [<ffffffff8151c0d1>] ? bch_btree_iter_next_filter+0x21/0x50
    [ 2138.360002]  [<ffffffff8151ca10>] ? btree_gc_count_keys+0x40/0x50
    [ 2138.360002]  [<ffffffff815212cd>] ? btree_gc_recurse+0x18d/0x2f0
    [ 2138.360002]  [<ffffffff8151c0dd>] ? bch_btree_iter_next_filter+0x2d/0x50
    [ 2138.360002]  [<ffffffff8151d4b4>] ? btree_gc_mark_node+0x54/0x220
    [ 2138.360002]  [<ffffffff8151d4b4>] ? btree_gc_mark_node+0x54/0x220
    [ 2138.360002]  [<ffffffff815219aa>] ? bch_btree_gc+0x3ea/0x510
    [ 2138.360002]  [<ffffffff81105360>] ? wait_woken+0x80/0x80
    [ 2138.360002]  [<ffffffff81521b00>] ? bch_gc_thread+0x30/0x110
    [ 2138.360002]  [<ffffffff81521ad0>] ? bch_btree_gc+0x510/0x510
    [ 2138.360002]  [<ffffffff810ecedc>] ? kthread+0xbc/0xe0
    [ 2138.360002]  [<ffffffff810ece20>] ? kthread_create_on_node+0x170/0x170
    [ 2138.360002]  [<ffffffff8166137c>] ? ret_from_fork+0x7c/0xb0
    [ 2138.360002]  [<ffffffff810ece20>] ? kthread_create_on_node+0x170/0x170
    
    Odstřelil jsem tedy to co nešlo vypnout korektně, odmountoval to co se nechalo (ne že by toho bylo moc, i pitomý sync se kousal), restartoval server a pokorně se vrátil ke kernelu 3.12. Následující pátrání mě pak dovedlo ke zjištění, že problém se projevuje s jádrem 3.14 a vyšším (jak s 3.13 nevím, gentoo-sources v téhle verzi nebyly k dispozici) a jde vlastně o dva problémy. Jednak registrace jakéhokoli cachujícího zařízení (čili cache na SSDčku) zvýší load o 1, jednak minimálně ve writeback režimu dochází k výše uvedeným deadlockům. Ten zvýšený load se po odregistrování zařízení nesníží, naopak po opětovné registraci se zvýší znovu o jedničku.

    Google mi popis této chyby našel, řešilo se to jak přímo na mailing listu tvůrců bcache, tak např. na fóru Archu. Bohužel vždy to nějak vyšumělo do ztracena. Každopádně jsem dospěl k závěru, že se o tom ví a snad se to řeší a bugreport jsem nikam nezadával - už proto, že moje samo domo angličtina je spíše read-only, takže nerad kamkoli píšu. Když jsem ale tento víkend zjistil, že problém trvá i v jádře 3.19, došla mi trpělivost a oznámil jsem to v bugzille Gentoo Linuxu (netušil jsem, kam jinam to psát). Výsledkem byl odkaz na tento patch, který podle všeho řeší alespoň problém s vytuháváním zápisů (respektive přežilo to víc než den opakovaných benchmarků pomocí programu fio, zatímco neopatchované jádro se obvykle kouslo po několika desítkách minut). Problém s loadem ale stále trvá, což je pro mě známkou, že tam je nadále někde něco shnilého a tak raději stále zůstávám u bezproblémového kernelu 3.12.

    Dodatek

    Vytuhnutí virtuálu s Windows mě obohatilo ještě o jednu zkušenost: současné NTFS považuji za poměrně robustní filesystem, který vydrží i docela hrubé zacházení. Ve Windows 2012 R2 přišel Microsoft s novinkou v podobě deduplikace dat a jejich následné komprimace. Bohužel jak se ukázalo, deduplikovaná data nejsou ponechána na úrovni filesytemu jako je tomu třeba u BTRFS, nýbrž strkají je "o úroveň výš" do databáze v adresáři "\System Volume Information\Dedup\ChunkStore\". A ta databáze je háklivá na nekoretní vypnutí a konkrétně v mém případě násilné vypnutí nerozdýchala. Další problém je v tom, systémový nástroj chkdsk určený pro kontrolu filesystemu takovéto chyby nenajde. Takže jsem ráno pro jistotu zkontroloval NTFS a až odpoledne jsem náhodou zjistil, že starší soubory nejde číst. Naštěstí byla sobota a navíc svátky, takže kupodivu nikdo neprudil a data jsem měl zálohovaná.

    Nicméně ačkoli mi deduplikace v daném případě ušetřila nějakých 44% volného místa, raději se do budoucna domluvím na přikoupení dalších disků, než abych riskoval, že zase přijdu o data. Deduplikaci mám aktuálně vypnutou a její opětovné zapnutí neplánuji.        

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Max avatar 18.2.2015 23:35 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Pěkný, díky za info.
    O deduplikaci jsem u MS nijak nevěděl, zajímavé, ale konečně jsme se dostali do stádia, kdy máme uspokojivou diskovou kapacitu, takže ok.
    Jen bych měl dotaz ohledně Keria Connect, proč jej provozuješ na windows serveru? Má to nějaký smysl/výhodu, o kterém nevím? Osobně mám aktuálně 330 licencí, asi 295 aktivních uživatelů a stoupám, cca 400GB zabráno na storage, cca 50 outlookářů s KOFF, hafo tabletů s připojením přes ActiveSync a pár thunderbirdů. Osobně mně překvapila svižnost rozhraní Keria a nenáročnost. Jedu na jednom jádru + 2GiB ram s tím, že budu rozšiřovat VM na 2xcore kvůli případným backupům, nebo balením archivů atd., které dokáží CPU vytížit.
    Mno, jinak u mně by takové uptime neprošly :-/, Jede se 24x7. To je také důvod, proč aktualizuji Kerio ojediněle, zrovna teď chystám větší update na aktuální verzi.
    Jinak postupně všechno sepisuji a snad se zadaří článek + porovnání s Exchange (máme 2007 a upgraduji na 2013) + porovnání s OpenSource (ladím teď SOGo + ActiveSync + klikací mgmt).
    Zdar Max
    Měl jsem sen ... :(
    18.2.2015 23:56 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Jen bych měl dotaz ohledně Keria Connect, proč jej provozuješ na windows serveru?
    Protože požadavkem bylo, aby v KOFF fungovalo SSO a nemuselo se explicitně zadávat heslo. A to Kerio na Linuxu neumí - anebo alespoň ještě na podzim neumělo a v changelogu jsem si změny nevšiml.
    Mno, jinak u mně by takové uptime neprošly :-/
    Já mám konkrétně tady (děláme víc firem) v noci naštěstí celkem klid, dělají jen přes den a pokud jim v jednu v noci otočím server, nevšimnou si toho ani notebookáři. V tomhle případě k tomu přispělo, že byl víkend, svátek a navíc téměř všichni jsou outlookáři a KOFF stahuje jen nové nebo změněné zprávy. A ty čitelné byly, deduplikace se aplikuje na soubory, na které pár dní nikdo nesáhl. O to problematičtější byla obnova z backupu, musel jsem promíchat soubory z toho dne s tím, co jsem vytáhl z databáze.

    Viditelně ten server nejel "jen" asi od pěti večer do dvou do rána. A jak jsem psal: víkend mezi svátky. Pár lidí si toho všimlo, ale nedělalo jim problém pochopit, že jsme měli havárii a že na tom pracujem. Je fakt, že ve všední den nebo když mají víkendovou zakázku, to by mě asi sežrali...

    Ostatní virtuály, které tam běží jsou duplikované (doménový řadič, DNS/DHCP...) nebo se využívají jen ve všední den.
    18.2.2015 23:57 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    co jsem vytáhl z databáze.
    ... pardon, ze zálohy, samozřejmě.
    19.2.2015 11:26 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Nedávno jsem zkoušel dm-cache na jádře 3.16 (Debian Jessie) a docela zklamání. Testoval jsem relativně primitivně - SQL bench na MySQL serveru. Na rotačním disku to běželo 10 hodin, na SSD 20 minut. Pak jsem nastavil SSD jako cache pro ten disk a protože cache byla větší než data, se kterýma pracoval ten MySQL server během testu, čekal bych výsledky blížící se běhu na SSD. Bohužel ne, běželo to 7 hodin. Zlepšení to je, ale žádná sláva.

    I když teď mě napadá, jestli by tomu trochu nepomohlo zapnout na filesystému DISCARD (tj. jestli dm-cache kód nebude dělat writeback pro data, co se mají smazat.)
    Quando omni flunkus moritati
    Max avatar 19.2.2015 13:01 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Mně se to jako zklamání tedy nejeví. Cache neznamená 100% nahrazení původního storage, ani když je cache 100x větší jak akcelerovaný storage.
    Zdar Max
    Měl jsem sen ... :(
    19.2.2015 13:39 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    To ano, ale mně se ji nepodařilo přinutit, aby zápisy byly nějak viditelně rychlejší než při přímém přístupu na rotační disk (writeback režim byl samozřejmě zapnutý). Nebo alespoň aby se to tak chovalo trvale a ne jen náhodou jednou za čas. Jak se zdá, nejsem sám. Narozdíl od bcache.

    Z uživatelského hlediska se mi dm-cache líbí víc, hlavně proto, že bcache v podstatě nejde zrušit, jde jen odpojit cachovací SSDčko, ale stále se tam musí lézt přes /dev/bcacheX. V případě dm-cache se nechá cachovaný mód beze zbytku zrušit. Jen kdyby to skutečně fungovalo i při zápisu. Snad časem...
    19.2.2015 13:47 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Mimochodem, zkoušeli jste někdo RAID co je přímo v LVM? Já včera zkoušel porovnat výkon klasického linuxového RAID1 vytvořeného pomocí mdadm a LVM RAIDu vytvořeného přes 'lvcreate --type raid1'. Při náhodném přístupu mi LVM dával asi tak poloviční IOPS, což mi oproti MD přijde docela bída. Možná jsem dělal něco špatně.

    Jádro 3.17, 2x WDC WD40EFRX v RAID1.
    19.2.2015 13:57 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Mimochodem, zkoušeli jste někdo RAID co je přímo v LVM?

    Nikdy jsem neměl tu potřebu. Pokud si pamatuju, tak podpora RAID v DM se dodělávala až v době, když MD už existovalo a běžně se používalo - když si můžu vybrat, preferuju kód, který používá víc lidí (protože je lépe otestovaný)
    Quando omni flunkus moritati
    19.2.2015 14:05 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Jak se zdá, nejsem sám.
    No, tam zrovna u dm-cache ukazuje docela dobré výsledky... ale možná to trochu vysvětluje ty moje
    Quando omni flunkus moritati
    19.2.2015 16:05 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    No dává, ale jen do zaplnění cache určené pro zápis dat. Když na filesystemu vypnul discard, tak mu šel výkon rapidně dolů (a mně taky, v podstatě na úroveň podkladového rotačního disku). Troufám si tvrdit, že v běžném provozu se data hned po zápisu na disk mazat nebudou, takže je důležité, aby se cache byla schopna ve writeback režimu nezapsaných dat zbavit dřív, než bude požadavek na další zapisování. Bcache má v tomhle směru docela hezkou samoregulaci rychlosti vyprazdňování; pokud je u dm-cache, tak jsem ji nenašel.

    Když jsem si to testoval já, tak při stejných testech mi dm-cache dávalo nějakých 400 iops, zatímco s bcache jsem se běžně pohyboval mezi 1400 a 1800 iops...
    19.2.2015 16:09 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Teď koukám, že vy jste měl discard vypnutý. Což by odpovídalo. Nějak mě nenapadlo, že by někdo měl SSD větší než podkladové úložiště, pak mi totiž použití takovéhle cache nedává smysl. :-)
    19.2.2015 21:39 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Když na filesystemu vypnul discard, tak mu šel výkon rapidně dolů
    Což to jasně, když jsou ty přístupy náhodné, tak se nedá moc čekat, že kód dm-cache dobře odhadne, co si má nechat a co ne. Vypnutý discard způsobil jenom to, že ta cache musela pracovat s backing device a projevilo se to.
    No dává, ale jen do zaplnění cache určené pro zápis dat.
    Zase, s náhodnými přístupy, což úplně neodpovídá reálnému provozu, kde se přece jenom k některým datům přistupuje více než k jiným.
    Troufám si tvrdit, že v běžném provozu se data hned po zápisu na disk mazat nebudou, takže je důležité, aby se cache byla schopna ve writeback režimu nezapsaných dat zbavit dřív, než bude požadavek na další zapisování. Bcache má v tomhle směru docela hezkou samoregulaci rychlosti vyprazdňování; pokud je u dm-cache, tak jsem ji nenašel.

    No, tady bych řekl, že už výkon s tím discardem nesouvisí. Pokud dobře chápu, tak jediné, o co mu šlo s tím vypnutým/zapnutým discard, je jaktože mají náhodné zápisy tak dobrý výkon. A závěr - protože se při formátování udělal discard, takže není potřeba při zápisu číst z backing device. Což jinak potřeba je - když se zapíší data menší než je velikost bloku v cache, musí se z backing device vytáhnout zbývající data, aby se do cache zapsal celý blok. A tak to v tom jeho testu bylo, bs=4k, nejmenší možná velikost chunksize je 32k (AFAIK)

    Naopak když se data nesmažou, tak by výkon měl být jenom lepší - když se je něco pokusí číst, tak jsou k dispozici.

    Na co jsme možná oba narazili, je fakt, že dm-cache se nesnaží fungovat jako cache pro všechno - v tom blogu je to dobře vysvětlené, že má zrychlovat přístup k místům, se kterými se intenzivně pracuje. Proto taky jeden zápis na nějaké místo na backing device nevyvolá zápis do cache, data jdou přímo na backing device a teprve když se na jedno místo zapisuje víckrát, dm-cache se rozhodne daný blok cachovat. Plus sekvenční zápisy úplně ignoruje.

    Nějaká štelovátka tam jsou. Teď zkouším, jak se u toho sql benchmarku projeví menší bloky pro cache. Zatím to vypadá, že menší blok = (v tomhle případě) větší výkon. Doběhně to až zítra, tak můžu zkusit vynutit, aby přes dm-cache šly všechny zápisy, co to udělá.

    I když je samozřejmě otázka, jestli v reálném provozu je takové nastavení lepší - přece jenom to sice urychlí zápisy, ale taky to agresivněji vytěsňuje data, což zpomaluje čtení. I když... čtení zas není takový problém, od toho jsou diskové cache v RAM...
    Quando omni flunkus moritati
    19.2.2015 22:30 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Na co jsme možná oba narazili, je fakt, že dm-cache se nesnaží fungovat jako cache pro všechno - v tom blogu je to dobře vysvětlené, že má zrychlovat přístup k místům, se kterými se intenzivně pracuje. Proto taky jeden zápis na nějaké místo na backing device nevyvolá zápis do cache, data jdou přímo na backing device a teprve když se na jedno místo zapisuje víckrát, dm-cache se rozhodne daný blok cachovat. Plus sekvenční zápisy úplně ignoruje.
    Tak tohle by mě zajímalo - v jaké situaci může nastat stav, kdy se opakovaně mnohokrát zapisuje na stejné místo? Disky hodně vytěžují třeba databáze, ale např. u multigeneračních systémů (jako třeba Postgres nebo Firebird) se i při přepisu zapisuje na nové místo a původní se jen označí jako uvolněné. Což koneckonců bude nejspíš i případ jakékoli činnosti na COW filesystemech. Co jinak? Podle mě se tímhle přístupem musí dost zužovat pole využití, ne?
    20.2.2015 01:23 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Disky hodně vytěžují třeba databáze, ale např. u multigeneračních systémů (jako třeba Postgres nebo Firebird) se i při přepisu zapisuje na nové místo a původní se jen označí jako uvolněné.
    Možná to nové místo není (z pohledu polohy na disku) úplně nové? Co mi běží ten benchmark, tak zrovna dělá insert into do innodb tabulky a poměr bloků zapsaných do cache a na disk je cca 10:1 (s write_promote_adjustment 2, tj. - jestli dobře chápu - do cache se ukládají bloky, kam se zapisovalo 2 a víckrát)
    Quando omni flunkus moritati
    Heron avatar 20.2.2015 08:23 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    se i při přepisu zapisuje na nové místo a původní se jen označí jako uvolněné

    To není úplně celá pravda. PG může provést zápis na řádek, který byl uvolněn, aniž by mezitím musel provést vacuum. Takže v případě, že dělám update jednoho záznamu pořád dokola, tak ten update může přepisovat jen dva řádky v datovém souboru na disku a může se stát, že oba budu v jedné 8kiB stránce. Takže pro disk se budou měnit jen dva 4kiB sektory (+ samozřejmě transakční log).

    Takže ssd cache to vůbec nemusí po každém zapisu commitovat až na hdd, ale jednou za čas tam stačí poslat ty dva 4kiB bloky (které se mezitím na tu cache poslaly nesčetně krát).

    Což koneckonců bude nejspíš i případ jakékoli činnosti na COW filesystemech

    Netudoval jsem nijak detailně vnitřnosti BTRFS, ale divil bych se, kdyby ten alokátor opravdu po každé změně na COW zvolil úplně jiný blok. Naopak bych čekal, že pokud může (pokud na ten starý blok nevede odkaz odjinud), tak bude stejně jako ta DB prohazovat nějaké dva.

    20.2.2015 09:39 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    OK.
    20.2.2015 11:28 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    No, tak to doběhlo, pustil jsem ten druhý test, ale mám ten pocit, že buď nechápu dokumentaci, nebo ta cache prostě funguje nějak divně.

    S nastaveným write_promote_adjustment na 0 bych čekal, že se do cache uloží všechno. To se zřejmě děje, write miss (zápis na rotační disk) je nula, všechno šlo do cache. Potud dobrý.

    Jenže když se podívám do iostat, tak je tam vidět řádově MB/s čtení z cache a stejně velký zápis na rotační disk - z té cache se na rotační disk intenzivně kopírují data, ten datový tok je dokonce větší, než co do té cache přichází. To by ještě mohlo bejt dobrý, řekněme, že je to writeback a že by to tak mělo fungovat. (No, přibližně, přece jenom ten stroj má hafo paměti, takže bych očekával, že writeback nebude potřebovat číst data z té cache.)

    Na druhou stranu ve výpisu stavu té cache se počet dirty bloků trvale pohybuje kolem 1, což podle mě znamená, že ta cache stíhá zapisovat data, která do ní přichází, na rotační disk pod sebou. A to už je divný, protože jediný způsob, jak to stihnout, je nějak přiškrtit zápisy přicházející od aplikace. A to se podle všeho děje - přestože se všechno zapisuje do cache a je v ní dost místa, ten SQL bench běží pomalu a rozhodně se tady nevyužije rychlost toho SSD.
    Quando omni flunkus moritati
    20.2.2015 11:51 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    No tak přesně tohle to dělalo i mně. Počet dirty bloků byl trvale velmi nízký (byť ne nenulový) a rychlost zápisu nestála za nic. Já si to předtím interpretoval tak, že blbne detekce sekvenčních zápisů, takže to do cache zapíše vždycky jen kousek a pak se to přepne do sekvenčního módu. Možná je to tak, jak píšete vy. Nebo úplně něčím jiným. Hlavně by mě zajímalo, jestli to je bug, nebo nějaká sofistikovaná vlastnost. :-)
    20.2.2015 12:40 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Já si to předtím interpretoval tak, že blbne detekce sekvenčních zápisů
    To mě napadlo taky, že se do toho motá - tak jsem zvedl sequential_threshold (počet spojitých I/O potřebných pro to, aby se přenos považoval za sekvenční) z původních 512 na 65536, což by se jen tak stát nemělo. Žádná změna.
    Hlavně by mě zajímalo, jestli to je bug, nebo nějaká sofistikovaná vlastnost.
    Jo, to je nás víc, ale koho se zeptat... U device mapperu je to vždycky stejné - ať už se člověk pokusí využít cokoliv, začne si velice brzo připadat, že je to nějaká obskurní vlastnost, kterou na webu popisuje akorát Red Hat a jeden blogger s Ubuntu.
    Quando omni flunkus moritati
    4.2.2016 18:09 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Trošku jsem si teď hrál s pgbenchem a dospěl jsem k závěru, že jako čtecí cache je lvm-cache dost dobrá - selecty nad databází se po nějaké době značně zrychlí, zvlášť pokud se sequential_treshold zvýší nebo nastaví na 0. Na druhou stranu ve writeback režimu je naopak vcelku na houby, protože si podle všeho vyprazdňuje cache na hlavní disk natolik agresivně, že se celý efekt prostě stírá. Tohle má bcache ošetřené mnohem líp, tam se rychlost přenosu dat z cache na hlavní disk mění v závislosti na intenzitě zápisů. Bohužel regrese v bcachi není vyřešena ani u jádra 4.4.0, takže pokud ji chci používat, musím stále zůstávat u verze 3.12 a z toho důvodu také uvažuji o přechodu na lvm-cache... :-(

    Ještě bych časem chtěl otestovat novější cache policy 'smq', kterou jádro 4.1.15-gentoo-r1, co mám na testovacím stroji, zatím neumí. Smq by měla být efektivnější, třeba se trošku zlepší i ten zápis. Takže až bude novější stabilní distribuční jádro...
    20.2.2015 20:07 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Možná to je naivní otázka, ale jste si jistý, co má být smyslem takové dvojice zařízení? Pokud smyslem je, že po zrušení páru má základní zařízení obsahovat všechna data, tak přirozeně každá bariéra (nebo fsync) způsobí zapsaní všech dat z vyrovnávacího zařízení do základního zařízení. A teprve až vše je sesynchronizováno, tak kešující zařízení může přijímat další zápisové operace.
    20.2.2015 20:47 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    To je nesmysl. Bariéry vám způsobí jen zápis na SSD a kdy si to systém zapíše na rotační disk je už jeho problém. Na perzistetním médiu to má, takže ztráta dat - narozdíl od stavu, kdy by to zůstávalo jen v RAMce - nehrozí. Samozřejmě za předpokladu, že se SSD či pevný disk nevysypou - proto je lepší mít ta SSDčka dvě spřažená do RAID1.
    20.2.2015 22:32 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Nesmysl to není, pokud po zrušení dvojzařízení máte mít zaručeno, že na základním zařízení je vše. Je to úplně stejné jako normální cache v disku.
    20.2.2015 23:37 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Jasně, ale pak je už levnější si dokoupit dostatek RAMky a cachovat do ní. Věci jako bcache, flashcache a předpokládám že i dm-cache jsou určeny pro zrychlení načítání a ukládání při náhodných přístupech na rotační disky, v podstatě suplují baterkou nebo flash pamětí zálohované řadiče. S tím, že by se za běhu bez přípravy rozpojovala obě zařízení se nepočítá.
    21.2.2015 07:47 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Vaše představa je mylná. Pokud (u bcache) SSD z nějakého důvodu vypadne, tak jsou data v pytli.
    21.2.2015 14:32 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Přidávám se k #33 - nic takového zaručeného nemáte. Nebo přesněji - když se rozhodnete cache zrušit, vyžaduje to flush dat na ten rotační disk a jde to, akorát to chvíli trvá. Když cache zařízení provozované ve writeback režimu umře, máte smůlu.
    Quando omni flunkus moritati
    19.2.2015 14:15 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Proč ne? Zrovna v tomhle nadsazeném případě bych řekl, že dokud se SSD cache nezaplní daty, protože rotační úložiště pod ní nestíhá, tak by měla fungovat na téměř nativní rychlosti toho SSD +/- nějaké zápisy metadat.
    Quando omni flunkus moritati
    19.2.2015 16:13 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Nevím jak u dm-cache, ale u bcache je pro zápis ve výchozím stavu vyhrazeno jen 10% celkové velikosti cache, zbytek je určen pro mezipaměť při čtení dat. Poměr se nastavuje v souboru /sys/block/bcacheX/bcache/writeback_percent.

    Mám pocit, že u dm-cache taky nějaké takovéhle rozdělení fungovalo.
    19.2.2015 21:07 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Kouknul jsem do /sys, ale nenašel jsem nic. Koukal jsem i do nastavení, které je vidět v dmsetup, ale také tam nic jako percent nebo ratio nevidím.
    Quando omni flunkus moritati
    19.2.2015 21:27 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    V nastavení dm-cache jsem možnost to konfigurovat také nenašel. Jen jsem to nekde zachytil, ale zaboha si už nemůžu uvědomit kde. Možná si to jen špatně pamatuju.
    19.2.2015 20:02 DIK
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Altenativa http://www.lessfs.com/wordpress/?p=924
    19.2.2015 20:33 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache

    My jsme driv @vpsFree pouzivali Flashcache, ale oproti ZFS a jeho schopnostem pouzivat SSD (L2ARC, ZIL) to stejne moc k nicemu nebylo. On totiz nejvetsim zabijakem u nas byl random write, ktery Flashcache, bcache i dm-cache akorat odkladaji, tomu seekovani se stejne neda vyhnout. Oproti tomu se ZFS se na SSD odplivava jenom neco jako "zurnal" a vsechny ostatni write - diky CoW designu ZFS - jsou linearni asynchronni zapisy.

    I kdyz pouziti Flashcache znatelne bylo, porad to nestacilo - obzvlast, kdyz nad tim jede nekolik (desitek) databazi, ktere syncuji jak o zivot.

    --- vpsFree.cz --- Virtuální servery svobodně
    19.2.2015 21:02 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Flashcache, bcache i dm-cache akorat odkladaji, tomu seekovani se stejne neda vyhnout.
    Tady by mě zajímalo, jak moc ty implementace cache umí sesbírat jednotlivé malé zápisy a dělat z nich větší. Tím by se seekování dost omezilo.
    Quando omni flunkus moritati
    19.2.2015 23:14 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Zkusil jsem, bcache to asi neumí, nechal jsem běžet fio s náhodnými zápisy po 512B blocích (vždy 30 sekund, před každým opakováním se vytvořil 512MB testovací soubor a po něm se zase smazal; discard jsem nechal vypnutý, takže cache se o smazání nedozvěděla) a po čase rychlost spadla na hodnoty jen nepatrně vyšší, než při zápisu na necachovaný disk. Prostě to chce mít čas od času nějaká klidnější období, aby si systém stihl alespoň část cache vylejt na disk.
    19.2.2015 23:43 Kvakor
    Rozbalit Rozbalit vše Re: Moje zkušenosti s bcache
    Možná, že by problém se zápisem velkého množství malých zápisú šel vyřešit žurnálem, který by ukládal nejden metadata, ale i data, řekněme do něčeho na způsob kruhového bufferu (u některých souborových systémů jde něco podobného zapnout, ale za cenu zhoršení výkonu, protože se zároveň zapisují i "nežurnálovaná" data). Malé zápisy by se "otagovaly", sdružily do velkého bloku a ten by se zapsal v jednom kuse a až dodatečně by se jednotlivé položky znova načetly a pozapisovaly na správná místa. Jinak řečeno, dirty data a writeback cache by se efektivně vyprázdnily na rychlé médium a teprve dodatečně by se z něj jednotlivé zápisy realizovaly na to pomalé (podobně, jako to nejspíš dělají uvnitř kombinované SSD+HDD disky).

    Sice by to znamenalo, že by se data navíc jednou četla a znovu zapisovala, ale to by so mohlo dělat, když by se zrovna s disky nepracovalo. Momo toho, při zápisu by šlo dělat mohutné optimalizace (hlavně zahazování zápisů do bloků, které byly později zas přepsány), včetně těch, které by nebyly při normálním zápisu možné kvůli bariérám. Tudíž by něco takového mělo smysly tam, kde se čas od času realizuje velké množství malých zápisů, ale po zbytek času je víceméně klid.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.