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í
×
dnes 02:00 | Nová verze

Turris OS, operační systém pro síťová zařízení Turris, byl vydán v nové major verzi 5.0. Vychází z OpenWrt 19.07.3. Podrobnosti na GitLabu.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Nová verze

Byla vydána verze 1.44.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

Ladislav Hagara | Komentářů: 0
včera 17:00 | Bezpečnostní upozornění

Nedávno byla vydána nová verze 9.4.6 nástroje pro řízení a správu IT zařízení a služeb GLPI (Wikipedie). Opraveno bylo několik bezpečnostních chyb. Například také SQL injection CVE-2020-11032 aneb email z ';-- Have I Been Pwned? dokáže smazat celý ticket systém.

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

MojeFedora.cz informuje, že Firefox 77 pro Fedoru přináší akceleraci videa. Firefox 77 pro Fedoru obsahuje patche, které konečně přináší podporu pro VA-API, tedy hardwarovou akceleraci videa. Podpora pro VA-API momentálně funguje pouze na Waylandu.

Ladislav Hagara | Komentářů: 4
včera 12:00 | Pozvánky

Sdružení CESNET dnes opět po roce pořádá jednodenní seminář věnovaný internetovému protokolu IPv6. Tentokrát on-line a s názvem Svět bez IPv4. K dispozici jsou také prezentace a záznamy přednášek z loňského roku.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Nová verze

Byla vydána nová stabilní verze 2.83 svobodného 3D softwaru Blender. Přehled novinek v oznámení o vydání a na YouTube. Jedná se o první verzi Blenderu s prodlouženou dvouletou podporou (LTS).

Ladislav Hagara | Komentářů: 4
včera 07:00 | Zajímavý článek

Jim Salter v recenzi pro Ars Technica srovnává novou generaci notebooků Dell XPS 13 s MS Windows 10 a Ubuntu (model „Developer Edition“). V obou případech naráží na problémy s výchozími ovladači: Wi-Fi Killer na Windows, chybná detekce ovladačů (audio čipu a Wi-Fi) od Dellu v Ubuntu.

Fluttershy, yay! | Komentářů: 12
3.6. 16:22 | Nová verze

Byla vydána verze 2.2 svobodné federalizované platformy pro sledování a sdílení videí, alternativy YouTube s podporou P2P, PeerTube (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Přispět lze na vývoj verze 3. V plánu je například podpora živého přenosu (live streaming). Za vývojem PeerTube stojí nezisková organizace Framasoft snažící se mimo jiné nahradit svými svobodnými Frama službami služby společnosti Google (De-google-ify Internet). Bohužel ale musí některé své služby omezovat.

Ladislav Hagara | Komentářů: 8
3.6. 07:00 | Komunita

Lenovo oznámilo, že bude certifikovat všechny své pracovní stanice řady ThinkStation a ThinkPad P pro Linux, konkrétně pro linuxové distribuce Red Hat Enterprise Linux a Ubuntu LTS. Doteď byly certifikovány pouze konkrétní modely.

Ladislav Hagara | Komentářů: 13
3.6. 00:44 | Nová verze

Oficiálně byl vydán Devuan Beowulf 3.0.0. Přehled novinek v poznámkách k vydání. Kódové jméno Beowulf je podle planetky s katalogovým číslem 38086. Příští verze 4.0.0 bude Chimaera. Devuan (Wikipedie) je fork Debianu bez systemd.

Ladislav Hagara | Komentářů: 0
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (36%)
 (18%)
 (6%)
 (13%)
 (10%)
 (6%)
 (15%)
 (22%)
Celkem 72 hlasů
 Komentářů: 2, poslední včera 19:05
Rozcestník
Zelený chameleon

Různé drobnosti a užitečnosti na které narazím nebo sám vytvořím. Primárně se zaměřuji na věci, které mohou být zajímavé a užitečné pro ostatní uživatele GNU/Linuxu či typografického systému TeX, občas se tu ale určitě vyskytne i něco z úplně jiného soudku, např. z oblasti bezpečnosti apod.

Aktuální zápisy

Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

3.10.2015 22:56 | Přečteno: 3546× | Btrfs | Výběrový blog | poslední úprava: 25.1.2016 15:03

Zhruba před rokem jsem na novém serveru vytvářel úložiště ze 4 kusů Hitachi 4 TB disků. Z hlediska bezpečnosti uložení dat jsem požadoval redundanci uložení (stačí dvě kopie) a samozřejmě čím vyšší rychlost, tím lépe. Už v té době jsem také předpokládal, že časem do serveru přibudou další disky a úložiště se bude rozšiřovat. Když k tomu ale teď došlo, tak jsem narazil u ext4 na limit 16 TiB velikosti filesystému. Skončilo to přechodem na Btrfs (podrobnosti dále) v produkčním provozu (byť ne kritickém), tak mi držte palce. ;-)

Původní úložiště

Softwarový RAID10

Vzhledem k uvedeným požadavkům a dostupnosti 4 disků jsem se tenkrát rozhodl pro RAID10. A to linuxový softwarový mdraid, protože s hardwarovými RAIDy jsou potenciálně potíže s rychlostí a určitě potíže s obnovou dat v případě havárie hardware. (Mimochodem mi zrovna teď leží na stole 10 let staré hardwarové pole Promise VTrak M500i, které z neznámého důvodu po nastartování nezprovozní síťová rozhraní pro iSCSI přístup k datům ani webový management pro správu. Přes konzolu na sériovém rozhraní je vidět, že bootování neproběhne korektně do konce. Data na něm uložená nebyla moc důležitá [a byla zálohovaná], takže mne to zas až tak moc netrápí, ale když bych je potřeboval dostat zpět, tak bych měl problém. Dosavadní pokusy o zprovoznění té škatule k úspěchu nevedly. V případě linuxového softwarového RAIDu bych disky jednoduše přestrkal do funkčního počítače s linuxem a bylo by.)

Instalovalo se na (v té době aktuálním) Debian 7 (Wheezy). Konzultací kernel Wiki a další zdrojů na webu jsem dospěl k závěru, že chci RAID10 ve far layoutu.

$ mdadm --create /dev/md0 --name storage --chunk=1024 --level 10 --raid-devices=4 --layout f2 --bitmap=internal /dev/sd[bcde]1
$ mdadm --detail --scan >> /etc/mdadm/mdadm.conf
$ dpkg-reconfigure mdadm
$ cat /proc/mdstat

Nastavení chunk size vzešlo tuším z nějakého přepočtu pro plánované LVM a ext4 filesystém.

Mimochodem, i po těch letech stále nedám dopustit na skvělou sérii Správa linuxového serveru na LinuxExpres.cz, která pokrývá např. i práci s Linux RAID.

LVM

Protože jsem už v té době tušil, že u 4 disků nezůstane, nedal jsem filesystém přímo na RAID pole, ale použil jsem mezivrstvu LVM.

Ne že by tedy vůbec nešlo rozšiřovat mdraid, ale je to výrazně komplikovanější a s omezeními. Pokud vím, tak mnou zvolený mód RAID10 (navíc ve far layoutu) pod mdraid stále není možné rozšířit o další zařízení. (A to ani na současném nejnovějším jádře, kterému to samozřejmě do stabilního Debianu ještě nějakou dobu potrvá.) Zpětně to považuji za velké štěstí, že jsem to vůbec neuvažoval dělat tímto způsobem, protože bych pak měl navíc velký problém nové disky z RAIDu uvolnit, až bych narazil na problém se zvětšením ext4, viz dále.

Postup přes LVM je jednoduchý:

$ pvcreate -M2 --dataalignment 1024K /dev/md0
$ pvdisplay
$ vgcreate --physicalextentsize 2048K mdraid10s /dev/md0
$ vgdisplay
$ lvcreate -n storage -l 100%VG mdraid10s
$ lvdisplay
$ pvs
$ vgs
$ lvs

Ani u LVM nezklame seriál LinuxExpres.cz. :-)

ext4

Pak už zbývalo jen vytvořit filesystém. Vzhledem ke stabilitě a dobrým zkušenostem jsem sáhl po klasice – ext4. Dá se zvětšovat (on-line) i zmenšovat (jen odpojený) a věřil jsem, že by neměl mít problém ani později na větších oddílech. Později se ukázalo, že jsem se měl více zajímat o reálné limity; moje zkušenost „nedostanu se k hardware, na který by současný běžně užívaný filesystém nestačil, není potřeba nad tím nějak hluboce dumat“ asi přestává platit.

Vytvoření jsem udělal dle spočtených parametrů:

$ mkfs.ext4 -b 4096 -E stride=256,stripe-width=512,resize=9766950400 -L storage -m 1 -T huge -v /dev/mapper/mdraid10s-storage

Po roce: Rozšíření úložiště o nové disky

Od té doby úložiště bez problémů dobře sloužilo, v mezičase jsme také přešli na aktuální Debian 8 (Jessie).

Nyní se stalo dříve očekávané, přišly další 4 disky, tentokrát 6 TB Western Digital Red, o které mělo být úložiště rozšířeno. Jal jsem se tedy aplikovat dříve plánovanou strategii – vytvoření nového samostatného RAID10 z nových disků, přidání pod LVM a roztažení ext4 přes celou nově dostupnou kapacitu logického oddílu.

GPT

I když to jde, nepovažuji za vhodné vytvářet RAID/LVM/Btrfs přímo na discích bez vytvoření patition tabulky (na jednom serveru jsem zdědil LVM přímo na discích a při instalaci operačního systému to vždycky bylo o jediný Enter od smazání všech dat, protože pro instalátor se disky jevily jako neinicializované). U 6 TB disků už je nutnost GPT, pro vytvoření jsem použil gdisk. Na každém disku jsem vytvořil jediný oddíl (s typem fd00 Linux RAID) přes skoro celý disk, protože jsem kdysi četl doporučení nevytvářet RAID přes úplně plnou kapacitu disků. Pokud je později potřeba nějaký disk vyměnit a bude to jiný model, může se stát, že i při proklamované stejné kapacitě to úplně na sektor sedět nebude a nastal by problém, pokud by takový disk byl menší než původní disky v poli.

Další softwarový RAID10

U nového pole jsem jen zopakoval to stejné, jako u pole minulého.

$ mdadm --create /dev/md1 --name storage2 --chunk=1024 --level 10 --raid-devices=4 --layout f2 --bitmap=internal /dev/sd[fghi]1
$ mdadm --detail --scan /dev/md1 >> /etc/mdadm/mdadm.conf
$ dpkg-reconfigure mdadm
$ cat /proc/mdstat

Nové pole do LVM

Nové pole jsem hned přidal do LVM a jediný logický svazek, který v LVM mám (slouží pro dané úložiště), jsem zvětšil na maximální velikost, aby pokryl celou nově dostupnou kapacitu.

$ pvdisplay
$ pvcreate -M2 --dataalignment 1024K /dev/md1
$ pvdisplay
$ vgdisplay
$ vgextend mdraid10s /dev/md1
$ vgdisplay
$ lvdisplay
$ lvextend -l+100%FREE /dev/mdraid10s/storage
$ lvdisplay
$ pvs
$ vgs
$ lvs

Rozšíření ext4 filesystému: selhalo

Všechno šlo hladce bez nejmenšího problému, a tak jsem poslední krok – rozšíření souborového systému ext4 na nově dostupnou kapacitu, tj. zhruba 18,3 TiB, – považoval za jasně bezproblémový. Úložiště jsem ani neodpojoval a jal se ho zvětšit za provozu:

$ resize2fs -p /dev/mapper/mdraid10s-storage                                        
resize2fs 1.42.12 (29-Aug-2014)                                                  
resize2fs: New size too large to be expressed in 32 bits

Tak to jsem vůbec nečekal. A když jsem si přečetl chybové hlášení, tak jsem hned tušil, že to asi nepůjde jen tak snadno spravit na již existujícím souborovém systému bez jeho nového vytvoření.

Rozšíření ext4 filesystému selhalo: co s tím

Přiznám se, že jsem se tenkrát nepodíval, jaké že má ext4 vlastně limity. Když jsem to teď pohledal, tak se ukázalo, že schopnosti ext4, respektive doporučené limity použití, se s časem vyvíjely, a i teď je u ext4 hranice velikosti oddílu 16 TiB stále významná, i když ne nepřekonatelná.

Nepouštěl jsem se do hlubších analýz, ale dle dvou článků nalezených na první pokus s vyhledávačem jsem nabyl dojmu, že mám čtyři možnosti:

  1. Rezignovat na jediný filesystém přes všechny disky.
    • V zásadě to ničemu nevadí do okamžiku, kdy bude na jednom svazku 0,5 TiB místa, na druhém 0,4 TiB místa, ale bude potřeba uložit 0,6 TiB soubor. Taky přesouvání dat už není jen úpravou v inode, ale musí se fyzicky přesouvat data atd.
  2. Na nových discích vytvořit nový logický LVM svazek a na něm nový 64bitový ext4 (dle /etc/mke2fs.conf to vypadá, že v Debian 8 už je to při vytváření ext4 filesystému default; můžu jen hádat, že na Debian 7 to tak ještě nebylo), přesunout tam data ze starého ext4 oddílu, a po jeho uvolnění staré RAID pole přidat do toho nového LVM oddílu a nový ext4 pak roztáhnout přes celou kapacitu obou polí.
    • Možná ale hrozí, že ani současná verze resize2fs z Debian 8 nebude umět zvětšit 64bitový ext4, takže bych si nepomohl. Jestli to tak opravdu je, nebo není, to jsem dále neověřoval, protože tu byla ta lákavá čtvrtá možnost, kterou jsem nakonec vyhodnotil jako nejlepší.
  3. Přejít na jiný „klasický“ filesystém, který má vyšší limity. Nejspíš tedy XFS.
  4. Vykašlat se na stabilní osvědčené ext4/XFS, LVM a linuxový softwarový RAID a přejít na Btrfs.

Migrujeme na Btrfs

Btrfs sice umí konvertovat ext4 oddíl na Btrfs i přímo, ale já se chtěl zbavit i níže ležící LVM a RAID vrstvy, protože Btrfs umí tohle všechno zastat sám. Musel jsem tedy nové disky zase vyprostit ze sevření LVM a rozbít na nich vytvořený RAID.

Vyjmutí pole z nových disků z LVM

V tomto místě jsem trošku zazmatkoval a zbytečně si to zkomplikoval. Vzhledem k tomu, že ext4 se zvětšit nepodařilo (tj. na jeho velikost a umístění na LVM oddílu se vůbec nesáhlo), bývalo by bylo stačilo zjistit velikost LVM oddílu náležejícího původnímu poli a LVM logický svazek takto zmenšit. Já však sáhl k bezpečnějšímu způsobu zmenšením existujícího ext4 oddílu (měl něco kolem 7,6 TiB) bezpečně pod velikost pole starých disků, zmenšení LVM logického svazku s bezpečnou rezervou tak, aby byl jistě větší než zmenšený ext4, a zároveň bezpečně menší než LVM fyzický svazek starého pole, aby bylo určitě možné fyzický svazek nového pole z LVM odebrat (tj. aby bylo kam přesunout data, která by na něm případně byla).

$ umount /mnt/storage
$ e2fsck -f /dev/mapper/mdraid10s-storage
$ resize2fs -p /dev/mapper/mdraid10s-storage 6400G
$ lvreduce -L 7200G /dev/mdraid10s/storage
$ pvmove /dev/md1
$ vgreduce mdraid10s /dev/md1
$ pvremove /dev/md1

Zrušení RAID z nových disků

Teď bylo možné zrušit softwarový RAID nad novými disky, aby se daly použít pro Btrfs pool.

$ mdadm --stop /dev/md1
$ mdadm --zero-superblock /dev/sd[fghi]1
$ vim /etc/mdadm/mdadm.conf # Odstranit záznam pro /dev/md1
$ dpkg-reconfigure mdadm

GPT pro Btrfs

Jak jsem psal výše, preferuji existenci diskového oddílu i při použití Btrfs. Pomocí gdisk jsem původní GPT zahodil a vytvořil novou, potřeba byly jen dvě změny – jako typ oddílu jsem nastavil 8300 Linux filesystem a oddíl jsem udělal opravdu přes celý disk, protože Btrfs nemá problém ani s kombinováním různě velkých disků.

Vytvoření Btrfs RAID10 pool

I v případě Btrfs jsem sáhl po RAID10, a to pro data i metadata.

$ mkfs.btrfs -L 'btrfs-pool' -m raid10 -d raid10 /dev/sd[fghi]1

Vytvoření okamžité, žádná dlouhá synchronizace jako v případě linuxového softwarového RAID. Vytvořený filesystém bylo možné okamžitě namountovat a začít používat.

Z hlediska budoucího využívání je u Btrfs vždy dobré necpat jakákoliv data přímo na kořen úložiště (tj. do subvolume 0), ale vytvořit si na vše podsvazky, ty samostatně připojit a data dávat tam. Pokud pak budete potřebovat dát na pole data mimo viditelnost běžných uživatelů, založit jiné logicky samostatné úložiště pro jiný typ dat atd., tak není nic jednoduššího, než přidat další podsvazky. Do /etc/fstab jsem tedy přidal

UUID=81616a44-bf88-4e99-a0c8-4d9d76c12aeb  /mnt/btrfs-pool  btrfs   noauto,relatime,subvolid=0    0 0
UUID=81616a44-bf88-4e99-a0c8-4d9d76c12aeb  /mnt/storage     btrfs   relatime,subvol=storage       0 0
a provedl
$ mkdir /mnt/btrfs-pool /mnt/storage
$ mount /mnt/btrfs-pool/
$ btrfs subvolume create /mnt/btrfs-pool/storage
$ rsync -avh --progress --delete /puvodni/uloziste/ /mnt/btrfs-pool/storage/
$ mount /mnt/storage/

Přípojný bod /mnt/btrfs-pool tedy slouží jako „servisní“, je připojován jen na vyžádání (ne automaticky po startu stroje) a vždy mountuje kořenový svazek Btrfs poolu (parametr subvolid=0 ve fstab) bez ohledu na to, co je případně jako defaultní svazek pro mount nastaveno. Skrze něj je tedy vždy dostupný kompletní obsah Btrfs poolu. Připojení /mnt/storage pak zpřístupňuje jen obsah podsvazku storage a je určen pro běžné použití úložiště i koncovým uživatelům.

Zrušení starého ext4 úložiště

Vzhledem k tomu, že nyní již byla všechna data na novém Btrfs úložišti (viz rsync výše), tak bylo možné zrušit původní ext4 + LVM + RAID, aby bylo možné staré disky přidat do Btrfs poolu.

# Zrušení LVM
$ lvremove /dev/mdraid10s/storage
$ vgremove mdraid10s
$ pvremove /dev/md0

# Zrušení mdraid ze starých disků
$ mdadm --stop /dev/md0
$ mdadm --zero-superblock /dev/sd[bcde]1
$ vim /etc/mdadm/mdadm.conf # Odstranit záznam pro /dev/md0
$ dpkg-reconfigure mdadm

# Vytvoření GUID diskových oddílů na starých discích
$ for i in b c d e; do
>     gdisk /dev/sd"${i}"
> done

Přidání starých disků do Btrfs úložiště

Zbývá poslední krok – uvolněné staré 4 kusy 4 TB disků přidat do Btrfs poolu, abychom tedy konečně měli k dispozici jeden souborový systém přes všechny disky. V případně Btrfs jednoduchá operace, která probíhá za plného provozu souborového systému, /mnt/storage/ teď už bylo celou dobu připojené a plně k dispozici uživatelům pro normální použití.

$ btrfs device add /dev/sd[bcde]1 /mnt/btrfs-pool/                                 
$ btrfs balance start /mnt/btrfs-pool/
$ umount /mnt/btrfs-pool/

Po rozšíření Btrfs svazku přes všechny disky je pro uživatelská data dostupných zhruba 18,5 TiB (fyzicky je na discích místa zhruba dvakrát tolik, ale je tam ta RAID10 redundance). V okamžiku před přidáním nových disků do serveru nebylo původní úložiště úplně plné, bylo tam uloženo jen asi 4,3 TiB dat, což byla tedy také zabraná kapacita (logická, fyzicky to je dvakrát tolik kvůli té RAID10 redundanci + servisní data filesystému) na Btrfs svazku po rozšíření přes všechny disky. Celkem to bylo něco kolem 2,5 milionu souborů. Za těchto podmínek ta balance operace (tj. rovnoměrné rozprostření dat z disků použitých už při vytvoření svazku také na disky do svazku nově přidaných) běžela zhruba 7,5 hodiny.

Údržba Btrfs

Stejně jako umí mdadm provádět kontroly shody redundantně uložených dat na mdraid (součástí dpkg-reconfigure je i načasování těchto kontrol), tak je vhodné provádět pravidelné kontroly a údržbu na Btrfs. Existuje na to i sada skriptů btrfsmaintenance, které jsou i standardní součástí v openSUSE repositářích. Pod Debianem o takovém balíčku nevím, takže jsem si skripty vyrobil sám přiohnutím těch z openSUSE.

Překartáčování“ úložiště jednoduše přečte všechna data ze všech disků a ověřuje přitom kontrolní součty, které si Btrfs interně pro všechna data vede. Pokud by narazil na chybu, tak by ji rovnou opravil, pokud by existovala jiná korektní kopie daných dat. Běží to s nízkou io prioritou, takže by to nemělo mít prakticky žádný vliv na běžné používání úložiště.

$ cat ~/bin/btrfs-maintenance-scrub.sh
#!/bin/bash

# Paths to work on
mountpoints=(/mnt/storage/)

for MNT in ${mountpoints[@]}; do

    echo "Running scrub on ${MNT}"

    if [ $(stat -f --format=%T "${MNT}") != "btrfs" ]; then
        echo "Path ${MNT} is not btrfs, skipping"
        continue
    fi

    /bin/btrfs scrub start -Bd "${MNT}"

    if [ "$?" != "0" ]; then
        echo "Scrub cancelled at ${MNT}"
        exit 1
    fi

done

Není špatný nápad čas od času přerozdělit data ze skupin bloků, které jsou málo využité (tj. je alokováno hodně místa na úložišti, ale je do něj zapsáno jen málo dat). Předchází se tak problémům, kdy je na discích dost místa, ale nejde využít, protože je rozkouskováno do mnoha málo využitých bloků).

$ cat ~/bin/btrfs-maintenance-balance.sh
#!/bin/bash

# Paths to work on
mountpoints=(/mnt/storage/)

# The usage percent for balancing data block groups.
# Caveat: the higher the longer it will need
BTRFS_BALANCE_DUSAGE="1 5 10 20 30 40 50"

# The usage percent for balancing metadata block groups.
# Caveat: the higher the longer it will need
BTRFS_BALANCE_MUSAGE="1 5 10 20 30"

/bin/btrfs filesystem show -d
echo

for MNT in ${mountpoints[@]}; do

    echo "Running balance on ${MNT}"

    if [ $(stat -f --format=%T "${MNT}") != "btrfs" ]; then
        echo "Path ${MNT} is not btrfs, skipping"
        continue
    fi

    echo
    echo "Before balance of ${MNT}"
    echo
    /bin/btrfs filesystem df -h "${MNT}"
    echo
    df -h "${MNT}"
    echo

    /bin/btrfs balance start -dusage=0 "${MNT}"
    for BB in $BTRFS_BALANCE_DUSAGE; do
        # quick round to clean up the unused block groups
        /bin/btrfs balance start -v -dusage=$BB "${MNT}"
    done
    /bin/btrfs balance start -musage=0 "${MNT}"
    for BB in $BTRFS_BALANCE_MUSAGE; do
        # quick round to clean up the unused block groups
        /bin/btrfs balance start -v -musage="$BB" "${MNT}"
    done

    echo
    echo "After balance of ${MNT}"
    echo
    /bin/btrfs filesystem df -h "${MNT}"
    echo
    df -h "${MNT}"
    echo

done

echo
/bin/btrfs filesystem show -d

Skript na defragmentaci jsem si připravil taky, ale pravda je, že prakticky jsem jej zatím nikdy nepoužil.

$ cat ~/bin/btrfs-maintenance-defrag.sh
#!/bin/bash

# Paths to work on
mountpoints=(/mnt/storage/)

# Minimal file size to consider for defragmentation
BTRFS_DEFRAG_MIN_SIZE="+1M"

for MNT in ${mountpoints[@]}; do

    echo "Running defrag on ${MNT}"

    if [ $(stat -f --format=%T "${MNT}") != "btrfs" ]; then
        echo "Path ${MNT} is not btrfs, skipping"
        continue
    fi

    find "${MNT}" -xdev -size "$BTRFS_DEFRAG_MIN_SIZE" -type f \
                -exec /bin/btrfs filesystem defrag -t 32m -f -v '{}' \;

done

Údržba se provádí Cronem, překartáčování úložiště jednou za měsíc, balancování každý týden.

crontab -l -u root | grep btrfs
@monthly                      /root/bin/btrfs-maintenance-scrub.sh
@weekly                       /root/bin/btrfs-maintenance-balance.sh

Na co dát pozor

Je potřeba myslet na to, že podsvazky vytvořené na Btrfs úložišti se tváří jako přechod mezi různými filesystémy, což může být podstatné, když např. pustíte find s volbou -xdev. Do podadresářů, které jsou ve skutečnosti Btrfs podsvazky, pak find nesestoupí.

$ cd /mnt/storage/
$ btrfs subvolume create zzz-podsvazek
$ touch zzz-podsvazek/zzz-soubor-na-podsvazku
$ find . -maxdepth 2 -type f | grep 'zzz'
./zzz-podsvazek/zzz-soubor-na-podsvazku
$ find . -xdev -maxdepth 2 -type f | grep 'zzz'
# tady se nevypíše nic, protože find do /mnt/storage/zzz-podsvazek/ nesestoupí
$ btrfs subvolume delete zzz-podsvazek/

Pro mne to má závažný praktický význam např. v tom, že klient páskové knihovny, kterou používáme pro zálohování, potřebuje vyjmenovat seznam filesystémů, které má zálohovat. Když mu řeknu zálohovat / a /mnt/storage/, tak musím myslet na to, že když někdo vytvoří na /mnt/storage/ podsvazky, tak ty nebudou zálohovány na pásky. To bohužel nebude zjevné např. ani z reportu, kterým si (ne)proběhnuvší zálohy sleduji, protože ostatní data z /mnt/storage/ budou korektně zálohovaná. V reportu tedy nebude vidět zjevná chyba ani nulová velikost zálohovaných dat z daného mountpointu. Tohle je ideální situace k tomu, aby člověk zjistil, že zálohu nemá, až v okamžiku, kdy ji bude potřebovat obnovit. :-/ Pozor na to!

Závěr

Do budoucna by nám přechod na Btrfs snad měl poskytnout větší bezpečnost dat (ve smyslu odolnosti vůči chybám hardware, bit rot apod.; naopak je možná vyšší riziko rozsypání se filesystému kvůli chybě v implementaci, protože je mladší a méně otestovaný než třeba ext2/3/4, XFS nebo ZFS), spoustu šikovných možností při používání úložiště (např. rychlé kopírování [díky copy-on-write pomocí cp --reflink], snapshoty podsvazků pro snadné uchování historických verzí dat, inkrementální zálohování, send/receive posílání dat na jiné úložiště, úsporu místa díky kompresi dat a deduplikaci apod.) a zejména volnost v další manipulaci s disky a růstu úložiště. Reálné limity velikosti filesystému a souborů jsou u Btrfs v exabytech, limit počtu souborů je 264. Netvrdím, že to už přece musí opravdu stačit každému (nemyslím si, že to inženýři od Sunu zbytečně přestřelili, když ZFS projektovali ještě výše), ale věřím, že pro naše použití to stačit bude. :-)

V tuto chvíli je pro mne podstatnější, že až vytáhnu směsku starších malých disků z té Promise škatule, kterou už se asi nebudu snažit dále resuscitovat, tak je můžu za plného provozu nejen fyzicky strčit do serveru, ale také začlenit do Btrfs uložiště a začít je používat. A to dost pravděpodobně i bez nevyužitelné kapacity, protože Btrfs je s rozdělováním dat mnohem gumovější než klasický linuxový softwarový RAID. A když v serveru dojdou pozice pro disky, tak můžu – stále za plného provozu filesystému pro koncové uživatele – starší disky průběžně vyndávat a nahrazovat je novějšími A když dojde místo a nebudou peníze na další disky, tak (opět za plného provozu) zdvojnásobíme dostupnou kapacitu přechodem z RAID10 na uložení dat bez redundance (a budeme spoléhat jen na zálohy). Tohle by tuším mělo jít definovat i na úrovni podsvazků (nebo dokonce i obyčejných adresářů?), takže je možné rozhodnout se, kde je vhodné držet data redundantně a kde si můžeme dovolit přejít na jednoduché uložení.

A že Btrfs ještě není dostatečně otestovaný pro produkční nasazení? No, to asi nepůjde udělat jinak, než se s tím někdo začne. Tak mi držte palce. :-)

       

Hodnocení: 95 %

        špatnédobré        

Anketa

V uvedeném případě bych
 (19 %)
 (15 %)
 (8 %)
 (2 %)
 (6 %)
 (51 %)
Celkem 53 hlasů

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

Komentáře

Vložit další komentář

4.10.2015 12:21 Ruda
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
A co výkon? Máš nějaké výkonostní statistiky starého a nového systému? Byť chápu, že přímo to porovnávat nelze, když došlo i ke změně HW konfigurace. A co nutnost remoutnout BTRFS při výpadku disku do degraded režimu? Asi teda neřešíš, když to není tak kritické.
Cohen avatar 4.10.2015 12:40 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Výkonnostní testy jsem nedělal, ale ten rsync ze starého pole s LVM a ext4 na nový Btrfs osciloval mezi 250–350 MiB/s, což mi přijde dobré. Dle nmon byly všechny disky rovnoměnrě vytížené plus mínus na 95 %, takže se nezdá, že by jedna strana (tj. softwarový RAID s LVM a ext4 nebo naopak ten Btrfs svazek měla být brzda procesu). Nějaký návrh na způsob testování rychlosti úložiště?

Výpadek disku (pokud nepadneme pod limit redundance, takže bychom přišli o data) by samozřejmě neměl být problém – existuje degraded mount volba, ale ta by neměla být potřeba, pokud je čitelný superblock, vadný disk by mělo stačit prostě za provozu ze svazku odebrat a případně nahradit jiným. Předpokládám, že ta degraded mount volba by měla jít kombinovat s remount, tj. nemělo by být nutné filesystém ani na chvíli odpojit.
OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
4.10.2015 13:45 pavele
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
A už jsi ten výpadek disku zkoušel nasimulovat? Myslím, že Heron měl k tomu kdysi nějakou řeč.
Cohen avatar 4.10.2015 14:55 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

Ne, nezkoušel.

Tím Heronem myšleno toto? No, to co píše mi trošku kazí představu o slučitelnosti mount voleb degraded a remount. Nepíše sice explicitně, že by to nešlo, ale předpokládám, že to nepůjde, když to tak neuděl. :-/

No, nebudeme se bát a zkusíme to:

$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (rw,relatime,space_cache)
$ mount -o remount,degraded /mnt/storage/
$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (rw,relatime,degraded,space_cache)
$ mount -o remount /mnt/storage/
$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (rw,relatime,degraded,space_cache)
$ mount -o remount,rw /mnt/storage/
$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (rw,relatime,degraded,space_cache)
$ mount -o remount,ro /mnt/storage/
$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (ro,relatime,degraded,space_cache)
$ mount -o remount /mnt/storage/
$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (rw,relatime,degraded,space_cache)
$ umount /mnt/storage 
$ mount /mnt/storage 
$ mount | grep btrfs
/dev/sdb1 on /mnt/storage type btrfs (rw,relatime,space_cache)

Zdá se tedy, že přepnout svazek do degradovaného módu je možné bez jeho odpojení, stačí použít mount volbu remount. Ale jak ho dostat pak zpět do normálního režimu jsem už jinak než s umount a mount nevymyslel.

Na druhou stranu je otázka, jestli by něčemu vadilo, pokud by po výměně disku zůstal filesystém připojený s flagem degraded, než by se např. stroj rebootoval nebo oddíle odpojoval z jiného důvodu. Myslím, že ne, a tak věřím, že by tedy disk mělo jít vyměnit bez nutnosti odpojení svazku.

OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
Heron avatar 5.10.2015 10:15 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Tím Heronem myšleno toto?

Asi jo ;-) :-)

V mém případě ani nešlo udělat remount,degraded. Musel jsem ten FS skutečně odpojit (ze všech mountpointů - připojuji si ještě i nějaké subvolumy zvlášť) a potom připojit jako degraded.

Zpět to také nejde, žádná volba "not degraded" neexistuje.

Na druhou stranu je otázka, jestli by něčemu vadilo, pokud by po výměně disku zůstal filesystém připojený s flagem degraded, než by se např. stroj rebootoval nebo oddíle odpojoval z jiného důvodu.

Ano, nad tím jsem také uvažoval a nějakou dobu jsem jel na degradovaném fs a vše bylo ok. Do vnitřností btrfs nevidím, ale z toho, jak se to chová, tak degraded je možná jen o nějakých kontrolách při mountu, dovolí běžet s menším počtem disků apod. a zbytek běhu fs je již stejný v obou případech.

Ono stejně je otázka, do jaké míry to vadí. V mnoha případech se ten komp stejně musí vypnout pro přendání disku a tam, kde není možné si výpadek dovolit, to mám řešené jako btrfs multidevice nad několika mdadm raid1. Takže btrfs výpadek disku nikdy neuvidí.

V každém případě je dobré o tomto chování vědět, způsobů, jak to obejít je dost. BTRFS se vyplatí i nad HW raidem, už jen pro ty vlastnosti, které nabízí.

Cohen avatar 5.10.2015 17:31 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

Mimochodem, co deduplikace dat na Btrfs? Nějaké praktické zkušenosti nebo doporučení?

OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
Heron avatar 5.10.2015 17:49 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Deduplikace na fs zní jako velmi dobrý nápad na papíře, ale (skoro) všechny implementace si na tom vylámaly zuby.

Deduplikaci je lepší provádět na vrstvě, která ví, které soubory budou z části nebo v celku stejné (a potom třeba využít věci, které btrfs nabízí, jako reflinky nebo clonovat (BTRFS_IOC_CLONE_RANGE) pouze část dat).

Dělat deduplikaci nad obecnými bloky (tzn si někam ukládat jejich hash + bezpečné manipulace při změnách) je velmi náročné na paměť a má to negativní dopad na výkon za mizivého přínosu co se ušetřeného místa týče.

To už je lepší se zamyslet nad způsobem ukládání dat a třeba se inspirovat od jiných projektů (git, backuppc, squashfs, některá řešení využívající db místo fs). Některé přístupy k problému jsou překvapivě jednoduché a účinné.
Cohen avatar 5.10.2015 20:20 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Dělat deduplikaci nad obecnými bloky (tzn si někam ukládat jejich hash + bezpečné manipulace při změnách) je velmi náročné na paměť a má to negativní dopad na výkon za mizivého přínosu co se ušetřeného místa týče.

Pro ZFS se tuším doporučuje 1 GiB RAM na 1 TiB úložiště, což tedy není málo.

To už je lepší se zamyslet nad způsobem ukládání dat a třeba se inspirovat od jiných projektů (git, backuppc, squashfs, některá řešení využívající db místo fs). Některé přístupy k problému jsou překvapivě jednoduché a účinné.

No, Btrfs stejně (zatím?) umí jen out-of-band deduplication. Kdysi jsem jen zkusmo párkrát použil v kernel wiki zmiňovaný duperemove, který pracuje, co si vzpomínám, tak, že se mu řekne, které soubory/adresáře má prohledat a deduplikovat. On si na datech napočítá kontrolní součty, a kde to vypadá na shodu, tam to nechá (kernel?) deduplikovat. Tohle mi právě smysluplné přijde – vím, že jsem zkopíroval velký soubor bez cp --reflink, tak na něj poštvu duperemove, vím, že jsem někam zkopíroval velký podstrom a udělal v něm sice změny, ale ne rozsáhlé, tak tam zase poštvu duperemove apod.

Z rychlého koukání do dokumentace si ale nejsem jistý, kdo že vlastně dělá tu vlastní deduplikaci, a jestli je to tedy bezpečné. Pokud by userspace nástroj napočítal kontrolní součty dvou bloků, zjistil, že jsou stejné a sám je nějakým systémovým voláním napojil na jedinou kopii, tak by IMHO hrozilo, že to spočítal blbě, nebo že se mu jeden z bloků změní v průběhu operace pod rukama. Předpokládám tedy, že takto to nefunguje. Víc o tom ale nevím a tam jsem tedy směřoval dotaz.

OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
Heron avatar 6.10.2015 09:43 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
On si na datech napočítá kontrolní součty, a kde to vypadá na shodu, tam to nechá (kernel?) deduplikovat. Tohle mi právě smysluplné přijde – vím, že jsem zkopíroval velký soubor bez cp --reflink, tak na něj poštvu duperemove, vím, že jsem někam zkopíroval velký podstrom a udělal v něm sice změny, ale ne rozsáhlé, tak tam zase poštvu duperemove apod.
Tak zrovna toto je triviálně proveditelné v userspace. Existují programy (např. hardlink), které nahradí stejné soubory hardlinky. Stačí příslušnou část programu upravit tak, aby na cow fs místo hardlinků dělal reflinky a je to.
nebo že se mu jeden z bloků změní v průběhu operace pod rukama
Může měnit jen soubory, které nejsou otevřené jiným procesem (nebo jen pro čtení).
msk avatar 6.10.2015 13:02 msk | skóre: 27 | blog: msk
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Zrovna vcera som skusal na deduplikaciu bedup. Ak som pochopil, tak pred tym, nez na subory hrabne, robi chattr +i, nasledne spocita hashe a pokial su rovnake, zavola kernel deduplikaciu. Nakonci odstrani 'i'.

Nijak zlvast som mu nenakladal, len kratucky testik, ale mam v plane to poriadne preskumat, pretoze pre to co momentalne robim je deduplikacia kriticka (staci mi offline).
Max avatar 5.10.2015 22:02 Max | skóre: 68 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Já nedávno nasadil FreeNAS se ZFS, začal jsem s kompresí a když mi backup běží 1,5Gbit/s (mám 2x1Gbit LACP a něběží mi to 2Gbit jen asi kvůli tomu, že ten LACP není ideální), tak jsem si řekl ok, je čas prubnout dedup, tak jsem jí zapl ná pár datasetech a uvidíme, kolik místa uspořím. Zatím mám 24TiB pole a 64GiB ram, takže rezerva je.
Zdar Max
Měl jsem sen ... :(
4.10.2015 20:34 Pavel Píša | skóre: 16 | blog: logic
Rozbalit Rozbalit vše Dotaz - jak postupovat v případě výpadku disku v RAID1.

Máte někdo zkušenost jak postupovat s BTRFS v případě, že dojde k (možná dočasné) chybě SATA řadič nebo disku?

Z nějakého důvodu přestal 3TB Seagate disk ST3000VN000-1H4167 komunikovat po SATA. HDPARM ho neviděl, smartclt se snažil asi přejít na starou verzi IOCTL, když nová neprošla a jádro si stěžovalo. Obecně byl disk nedostupný. BTRFS korektně po několik dní pokračovalo v režimu RAID1 a bez potíží zvládalo i zápis. Disk byl přítomný, jen nekomunikoval.

ata2.00: failed command: WRITE FPDMA QUEUED
...
ata2: hard resetting link
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata2.00: both IDENTIFYs aborted, assuming NODEV
ata2.00: revalidation failed (errno=-2)
ata2.00: disabled
ata2: EH complete
sd 1:0:0:0: [sdb] tag#1 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sdb] tag#1 CDB: Write(16) 8a 00 00 00 00 00 06 01 09 00 00 00 00 18 00 00
sd 1:0:0:0: [sdb] tag#2 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sdb] tag#2 CDB: Write(16) 8a 00 00 00 00 00 06 01 08 80 00 00 00 80 00 00
blk_update_request: I/O error, dev sdb, sector 100731008
BTRFS: bdev /dev/sdb5 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
sd 1:0:0:0: [sdb] tag#3 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 1:0:0:0: [sdb] tag#3 CDB: Write(16) 8a 00 00 00 00 00 06 01 08 00 00 00 00 80 00 00
blk_update_request: I/O error, dev sdb, sector 100730880
BTRFS: bdev /dev/sdb5 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0
...

Přes všechny snahy resetovat SATA disk (hdparm -w) a řadič se mi nepodařilo disk kontaktovat. Zjistil jsem, o který fyzický disk se jedná a zkusil vyměnit SATA kabel. Při snaze o scan

# readlink -f /sys/block/sdb
/sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sde

echo '- - -' >/sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/scsi_host/host1/scan

hlásí dmesg stále

ata2: hard resetting link
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: both IDENTIFYs aborted, assuming NODEV
ata2: EH complete

Po dokončení zálohy na externí USB disk jsem přikročil k násilnému vyjmutí a zasunutí napájecího konektoru problematického disku. Nyní již echo '- - -' >scan vypadá až na rychlost relativně dobře.

ata2: hard resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: COMRESET failed (errno=-16)
ata2: hard resetting link
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: ATA-9: ST3000VN000-1H4167, SC43, max UDMA/133
ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: configured for UDMA/133
ata2: EH complete
scsi 1:0:0:0: Direct-Access     ATA      ST3000VN000-1H41 SC43 PQ: 0 ANSI: 5
sd 1:0:0:0: [sde] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
sd 1:0:0:0: [sde] 4096-byte physical blocks
sd 1:0:0:0: [sde] Write Protect is off
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: [sde] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
BTRFS: bdev /dev/sdb5 errs: wr 8494906, rd 6076119, flush 29099, corrupt 0, gen 0
BTRFS: bdev /dev/sdb5 errs: wr 8494907, rd 6076119, flush 29099, corrupt 0, gen 0
...
sde: sde1 sde2 sde3 sde4 sde5 sde6
sd 1:0:0:0: [sde] Attached SCSI disk
ata2: hard resetting link
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: configured for UDMA/133
ata2: EH complete

Je disk dostupný jako /dev/sde. Stále je asi v jeho připojení něco divného, ale nezávislá samostatná EXTč partition lze normálně mountovat a lze do ní zapisovat. smartcl hlásí vše v pořádku a v uvádí jen jeden rok a půl starý problém Error: ABRT at LBA, pravděpodobně výpadek napájení. Jinak je čistý.

BTRFS sice správně po po načtení tabulky GPT oddílů detekuje příslušnost /dev/sdb5 k aktivnímu RAID1. Přesto sále vypisuje:

BTRFS: lost page write due to I/O error on /dev/sde5
BTRFS: bdev /dev/sde5 errs: wr 11007593, rd 8526080, flush 29099, corrupt 0, gen 0
...

Zkoušel jsem pustit scrub, ale jen hlásí chyby na sda5. Nepodařilo se mi najít žádný jiný příkaz, který by měl v popisu, že zkusí vše načíst a srovná verze mezi kopiemi dat. Doufám, že alespoň stará data nebudou nikde použita na místo nových. Jsem přesvědčený, že přidání nového disku a

btrfs replace

by fungovalo. Ale zatím další disk po ruce nemám a běží mi

smartctl -t long /dev/sde

a pokud nevyhlásí chybu, tak nejsem přesvědčený, že je nutné disk vyřadit. Řešení by také bylo

btrfs device delete /dev/sde5 /
btrfs device add /dev/sde5 /
btrfs balance start -mconvert=RAID1 -dconvert=RAID1 -sconvert=RAID1 /

Není ale nějaký jednodušší způsob kdy i se využijí i data, co jsou disku který vypadl. Teoreticky vyjmutí disku při nějaké nepovšimnuté chybě na disku co běží stále, znamená ztrátu dat. Pokud by se jednlo o klasický RAID1 tak se při synchronizaci použijí data z obou disků. Věřím/doufám, že BTRFS je také v tuto chvíli třeba pro rescue, restore a i čtení za běhu použít dokáže.

5.10.2015 09:17 R
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.
Pri klasickom RAIDe 1 sa data na disku, ktory je neaktualny (bol vyradeny z pola z lubovolneho dovodu), musia prepisat aktualnymi datami.
5.10.2015 09:59 Pavel Píša | skóre: 16 | blog: logic
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.

Pokud byl vyřazený tak s tím souhlasím. Ale pokud se jedná jen o dočasnou ztrátu komunikace, tak bych preferoval řešení, kdy se dají ta data, která jsou na trvale běžícím disku nečitelná, nahradit daty z druhého disku. I když je pravda, že alespoň servisní informace o aktuálnosti bloků musí být čitelná z obou disků.

Vzhledem k tomu, že BTRFS drží generace k jednotlivým inode/záznamům, tak si představuji, že by se ty části, kde se ještě generace ani na trvale přítomném disku nezměnila, mohly v případě problému využít z toho dočasně vypadlého disku. Zároveň po kontrole konzistence dat na vypadlém disku není důvod data, která se neměnila, přesouvat.

Alespoň si myslím, že by to takto mělo jít zařídit, výrazně by to zkrátilo synchronizaci a zároveň by to dávalo naději získat kompletní neporušená data, pokud se vyskytne jen malé množství chyb na obou discích nebo disku, který byl trvale přítomný.

Nezkoumal jsem, jestli výše popsané možnosti nějaká implementace RAID nabízí a zatím se mi zdá, že BTRFS je nenabízí. Takže děkuji za názor, který výše uvedené možnosti zamítá. Předpokládal jsem že servisní data (checsum/nějaká informace o pořadí v sekvenci zápisu) by u klasického RAID to mohla řešit stejně jako případ chybě čtených bloků, ale do kódu jsem se zatím nedíval. Budu rád, pokud mi neexistenci této možnosti potvrdí i další.

PS: smarctl -t long doběhl bez chyby. U předchozí jediné logované chyby jsem se spletl ve výpočtu času a ve skutečnosti power-up hours spadá do období, kdy došlo k ztrátě komunikace s diskem. Logovaná událost

Error 1 occurred at disk power-on lifetime: 10879 hours (453 days + 7 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 71 09 a9 00 80 40  Device Fault; Error: ABRT at LBA = 0x008000a9 = 8388777

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 00 18 00 09 01 46 00   4d+15:27:59.335  WRITE FPDMA QUEUED
  61 00 80 80 08 01 46 00   4d+15:27:59.335  WRITE FPDMA QUEUED
  61 00 80 00 08 01 46 00   4d+15:27:59.335  WRITE FPDMA QUEUED
  61 00 80 80 07 01 46 00   4d+15:27:59.335  WRITE FPDMA QUEUED
  61 00 68 18 07 01 46 00   4d+15:27:59.335  WRITE FPDMA QUEUED

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     11260         -
# 2  Short offline       Completed without error       00%     11253         -
5.10.2015 13:27 R
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.
mdraid podporuje write-intent bitmapu - ta umoznuje urobit ciastocny resync po vybrati/vlozeni disku (aktualizuju sa len zmenene bloky).
5.10.2015 10:50 Aleš Kapica | skóre: 50 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.
Není to sice přímá odpověď, ale cesta.

Můj problém spočíval v tom, že v ramdisku chyběl nástroj btrfsck (ten se obvykle nalézá v adresáři /bin a knihovna libgcc_s.so.1, která je v /lib/x86_64-linux-gnu. Bez btrfsck nelze v ramdisku provést opravu nakopnutého BTRFS a bez té knihovny se zase pro změnu nedá spustit scrub.

Háček je v tom, že btrfsck se nespouští na namountovaný BTRFS FS, ale přímo na zařízení. Pokud je FS namountované - byť v read-only režimu, tak příkaz selže. Tudíž je třeba, aby byl tento nástroj v ramdisku. Pro scrub platí naopak, že FS musí být namountovaný v rw režimu, jinak nepjede. Takže..
  1. Oprava FS na jednotlivých /dev/.. odmountovaného Btrfs
  2. Namountování opraveného Btrfs FS v zapisovatelném režimu
  3. Spuštění akce scrub na namountovaný Btrfs FS
A na výsledek jsem sám zvědav.. Scrub právě běží.. ;-)
5.10.2015 11:05 Aleš Kapica | skóre: 50 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.
Takže - systém opraven, po restartu normálně běží a vše ok. Teda.. až na vadný datový SSHD disk, který to vše způsobil a je aktuálně v reklamaci..
5.10.2015 13:19 Aleš Kapica | skóre: 50 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.
Na Pavlovo přání ještě přidávám pro úplnost jak vypadal příkaz pro opravu Btrfs:

btrfsck --repair --init-extent-tree --init-csum-tree /dev/sda1

Vyzvracelo to za běhu na konzoli hromadu děsivých zpráv, ale výsledek je funkční FS a bez chyb.
8.10.2015 18:55 Pavel Píša | skóre: 16 | blog: logic
Rozbalit Rozbalit vše Re: Dotaz - jak postupovat v případě výpadku disku v RAID1.

Tak nakonec jsem zvolil strategii, btrfs replace dočasně vypadlého disku za nový a druhý replace, abych data dostal na disk zpět. Zdá se, že update s udržením možnosti čtení dat z kopie bez přesunu dat možný není - inplace sync. Diskutovaná byla alternativa na disku, který má data zastaralá zlikvidovat identifikaci BTRFS (první sektory smazat) a pak provést remove missing nebo provést delete a pak opět add a balance. Ale to je všechno se značným rizikem, protože po dobu obnovování budou data jen v jedné kopii. Odpověď na můj dotaz v BTRFS mailing listu:

http://article.gmane.org/gmane.comp.file-systems.btrfs/48930/match=

nebo zde, kdy6 m8 GMANE potíže

https://www.marc.info/?l=linux-btrfs&m=144430491713231&w=2

Obecně se zdá, že BTRFS vždy pracovalo s aktuálními daty a data plněně ochránilo.

msk avatar 5.10.2015 09:57 msk | skóre: 27 | blog: msk
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Perfektna praca, myslim ze pomoze dalsim ludom skusajucim btrfs. Ja mam v plane doma prejst z SOHO DLink NAS-u 2x2TB ext3 na "pc skladacku" 2x4TB btrfs-raid1, zatial som vychadzal z Heron-ovho blog-u, ale tie scripty Ti ukradnem, diky - na pravidelny scrub ani rebalance som moc nemyslel.
5.10.2015 12:41 Aleš Kapica | skóre: 50 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
A že Btrfs ještě není dostatečně otestovaný pro produkční nasazení? No, to asi nepůjde udělat jinak, než se s tím někdo začne. Tak mi držte palce.
Šoupání s daty - publikováno 29.1.2012; Fanless computer - bezvětrákový stroj bez kompromisů - publikováno 7.1.2013; V obou případech jde o jeden a týž Btrfs souborový systém, který si to kroutí už čtvrtým rokem na našem domácím úložišti. V produkčním nasazení používám Btrfs od října 2012 (viz Využití Btrfs k denním zálohám studentských účtů (říjen 2012). A na rozdíl od ext4 jsem u tohoto FS o data nikdy nepřišel - byť mi místy řádně lepilo. Co si tedy představujete pod pojmem - "dostatečně otestovaný"?

5.10.2015 13:55 Ruda
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Já bych si pod tím představoval, to že při vadném disku ho odpojím a zašoupnu nový, zadám pár příkazů a systém jde bez restartu nebo divných hlášek. To vše mi krásně na dmraid s ext4/xfs funguje, ale jak čtu od tebe něco o ramdisku, restartech a podobně tak se mi to s BTRFS nezdá tak bezproblémové, leda že bys nepoužíval na BTRFS failsafe mechanismy.
Heron avatar 5.10.2015 14:27 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Vůbec nic vám nebrání si nad tem dmraid dát místo ext4/xfs btrfs a budete to mít úplně stejně bezproblémové a budete mít všechny výhody btrfs, které na ext4/xfs nemáte + ještě bezproblémovou výměnu disků.

Tím chci říct, že trochu porovnáváte neporovnatelné. ext4/xfs nepřežijí výpadek disku, protože jsou pouze nad jedním diskovým zařízením. btrfs v multidevice raid1 (a další redundantní) jej přežije. To, že to zatím není tak skvělé a radostné jako u mdadm je taky třeba dáno tím, jak dlouho tady ten projekt je a co všechno řeší. multidevice block je v linuxu od 2.2 (tedy patrně ještě mnohem dřív, tak daleko moje paměť nesahá) a řeší jen blokové zařízení. BTRFS začalo vznikat někdy v 2008, do kernelu se dostalo v roce 2009. To je tedy nějakých 6 let. A samozřejmě řeší hromadu dalších věcí než jen multidevice.

Jen pro srovnání, XFS je vyvíjeno od roku 1994, do linuxu se dostalo v roce 2001 a trvalo dalších 14 let, než jej významná distribuce (RHEL) zařadila jako default fs. (XFS pochopitelně mohl kdo chtěl používat již kdykoliv dříve.)

To jen pro ilustraci, jak dlouho to asi tak trvá.
15.10.2015 14:21 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
To, že to zatím není tak skvělé a radostné jako u mdadm je taky třeba dáno tím, jak dlouho tady ten projekt je a co všechno řeší.

A možná taky tím, že se vývojáři btrfs neobtěžovali zjistit, jestli by náhodou nešlo využít existující jaderné implementace kombinování blokových zařízení a případně je rozšířit o to, co ten filesystém potřebuje navíc. Jednodušší zjevně bylo přidat do jádra třetí implementaci RAIDu.
Quando omni flunkus moritati
Heron avatar 15.10.2015 16:00 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Jednodušší zjevně bylo přidat do jádra třetí implementaci RAIDu.
Pojetí redundace v btrfs je zcela odlišné od raidů nad blokovým zařízením exportující další blokové zařízení. Btrfs nemá žádnou raid vrstvu, která by šla (i třeba jen teoreticky) exportovat jako blokové zařízení*. Btrfs řeší redundanci jen jako zápis extentů na vícero zařízení, přičemž ty bloky na dvou různých zařízeních snad ani nejsou stejné a už vůbec ne na stejném místě. Ty bloky by se klidně mohly ukládat i třeba s jinou kompresí (podpora pro to samozřejmě není, ale návrhu to neodporuje).

*) Tak to má třeba ZFS, které spojuje device do vdev a vdevy do poolu, ze kterého můžete exportovat block device a filesystem. Tohle má některé výhody (jako třeba možnost snapshotů těch zvolů), ale taky nevýhody v podobě neměnnosti vdevů (pokud se něco nezměnilo, tak jednou postavení vdev nelze měnit - přidat, odebrat disk).

Btrfs toto řeší jinak, bloková zařízení jsou prostě jen zásobárna bloků a btrfs nad tím rozhazuje bloky souborů po různých block device.

(Což s sebou přináší další možnosti, třeba v podobě možnosti kdykoliv kterýkoliv disk nechat uklidit a odebrat z btrfs apod. a samozřejmě zase jiné problémy.)

15.10.2015 17:55 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Ale RAID přece neznamená, že ty bloky musí být na stejném místě nebo že se nemohou komprimovat. Tohle "zcela odlišné" pojetí by se dalo získat rozšířením raid targetu v device mapperu a fungovalo by to stejně - bez duplikace kódu a s tím spojenými lety práce navíc.
Quando omni flunkus moritati
Heron avatar 15.10.2015 18:33 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Rád se nechám poučit. Co všechno nabízí (dvě) implementace raidu v kernelu dopodrobna nevím, vím jen, že z toho do userspace vyrůstají věci jako (md) mdadm (blokové zařízení složené z blokových zařízení), (dm) lvm (totéž) a tak jak znám tyto systémy v praxi, tak nevídím možnost cokoliv z toho použít pro btrfs. (Pochopitelně krom v podstatě obecných fcí pro výpočet parity, csum apod.)
5.10.2015 15:07 Aleš Kapica | skóre: 50 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Vtip je v tom, že když už tady o něčem píšu, tak proto, že to není banální operace kterou zvládne každý kdo má do prdele díru. A píšu o tom právě proto, abych ostatním ušetřil svoje vlastní tápání při hledání východiska. Ne proto, že by to bylo řešení standardní situace. Od toho je manuál.
=^..^= AmigaPower® avatar 5.10.2015 20:03 =^..^= AmigaPower® | skóre: 30 | blog: BLB | Praha
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Ony ještě dělaj? Obchoďák z PCV Comp mi řikal, že kromě velký dvojky disky dělá už jen Toshiba...
Cohen avatar 5.10.2015 20:09 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Jestli se nepletu, tak Hitashi teď patří pod WD. Jak to mají fyzicky organizované, to nevím, ale prodává se to stále s nálepkou Hitashi (nebo to tak bylo před tím cca rokem) a podle statistik mají Hitashi disky stále ještě výrazně vyšší spolehlivost než WD. A ten má zase vyrazně vyšší než Seagate. Statistiky disků Toshiba jsem neviděl. Když mi ale odešel disk Toshiba v notebooku, tak se servisák tvářil, že Toshiby odchází jak na běžícím páse a je lepší dát tam WD (ale znáte to, jedna paní povídala + osobní anipatie).
OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
=^..^= AmigaPower® avatar 5.10.2015 20:42 =^..^= AmigaPower® | skóre: 30 | blog: BLB | Praha
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
s 2.5 diskem Toshiba mám podobnou zkušenost, vlastně bych to s těma diskama viděl asi tak "naprosto stejně" :-D
5.10.2015 22:10 00000 | skóre: 7 | blog:
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
No vida, jak se to tu rozjelo.

Díky Heronovi jsem si do virtuálu zkusil nainstalovat btrfs a přeplnit jej daty pár snapshoty, abych si ověřil, co to udělá, pak něco vymazat a provést rebalance kvůli přeplnění snapshoty.

Zdá se, že to bude vynikající na zálohování, jednoduché a funkční.
Cohen avatar 5.10.2015 22:26 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

Jo, snapshoty jsou (vedle checksumů všech dat) jednou z hlavních killer features Btrfs. Sám ho na zálohování taky používám. (Ovšem čestně přiznávám, že zatím stále ještě v kombinaci s rdiff-backup na ext4. Ono je ale asi vždycky lepší zálohovat alespoň na dva různé filesystémy.) Existuje na to několik nástrojů, ale IMHO je to všechno na téma rsync && read-only snapshot (maximálně doplněné o send/receive s jiným strojem), takže jsem si to napsal taky po svém.

Podstatné je asi jen pouštět ten rsync s parametry --inplace a --no-whole-file, aby se pokud možno nesahalo na části souborů, které nebyly změněné, a tak se maximálně šetřilo místo zachováním jediné kopie dat, která je pak odkazovaná ze všech snapshotů.

OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
Heron avatar 6.10.2015 11:26 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Ovšem čestně přiznávám, že zatím stále ještě v kombinaci s rdiff-backup na ext4.
Já kombinuju zálohování pomocí snapshotů:
  • snapshot fs na zdrojovém serveru
  • rsync toho snímku na cílový (tady přemýšlím, zda to už nenahradit za btrfs send / receive)
  • snap na cílovém serveru (aby bylo několik záloh do minulosti - aktuálně něco přes 600)
  • volitelné smazání snímku na zdrojovém serveru (klidně se tam může ponechat pro snadné lokální obnovení smazaného souboru a vést si historii snapshotů i na zálohovaném serveru)
ještě se squashfs, kam strkám data snapshotů a tento squash ukládám na XFS. Squashfs má deduplikaci bloků + komprimaci a data konkrétné subvolume se při denním zálohování nemění, takže je to velmi účinné (jen se to časem velmi zpomaluje a je třeba udělat nový čistý squashfs).
7.10.2015 11:47 kolcon | skóre: 15 | blog: kolcon
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

pekny clanek, neresil jsi nahodou i situaci, kde by raidX btrfs bezel na vice zakryptovanych discich? (vcetne rootu)

disk 1 - LUKS -- btrfs raid nad temi LUKSy?

disk 2 - LUKS -/

 

Vlastne otazka je, jak odemknout oba zakryptovane disky a teprve potom nad tim sestavovat ten btrfs a mountovat rot

... aniz bych musel delat vlastni initram...

Cohen avatar 7.10.2015 12:01 Cohen | skóre: 21 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

Kryptování? To je nějaká zábavná hra v kryptách? :-) Z odkazů na LUKS odhaduji, že mohlo být myšleno šifrování, ale co to má společného s kryptami... ;-)

To jsem ale nezkoušel, takže neporadím. :-/ Typově mne ale nenapadá, proč by se to mělo lišit od libovolného jiného filesystému. Jen je tedy potřeba dešifrovat všechna používaná zařízení na začátku, než může dojít k pokusu o mount Btrfs RAIDu. Jaký je problém s tím odemčením obou disků současně?

OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
7.10.2015 12:04 kolcon | skóre: 15 | blog: kolcon
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs

u jinych fs jsem to resil mdraidem a ten LUKS byl az nad nim. Slo by to tak i u btrfs, ale chci prave zkusit tu mdraid vrsvtu vynechat...

Heron avatar 7.10.2015 12:43 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Před připojením multidevice btrfs je třeba spustit btrfs device scan (což se spouští v initramfs). Nevím, zda se to dělá až po otevření luks, to už je věc jednotlivé distribuce.

Pokud to není multidevice, tak je to nijak neliší od mountu na blokovým zařízením.
11.10.2015 10:52 kolcon | skóre: 15 | blog: kolcon
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
tak nakonec jsem mirne poupravil debiani "standardni" initramfs...
13.10.2015 20:48 kolcon | skóre: 15 | blog: kolcon
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
jen pro zaznam - nakonec to debiani initram zvladne sam, staci mit spravne /etc/crypttab
18.10.2015 08:32 Jenda
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
Díky za článek, takovéto povzbuzující zápisky velice chybí.

Minulý víkend jsem se pod dojmem tohoto blogu konečně rozhoupal, že bych btrfs hodil na zálohovací systém, abych tam měl pěkně ty data pojištěný přes checksumy, ale odpoledne mi do toho něco vlezlo a v týdnu jsem přes systemd narazil na článek, že se CentOS pokorně vrací z btrfs na ext4.

Ve stabilním Debianu je jádro 3.16 a sám autor btrfs tvrdí, že teprve 3.19 opravila několik zásadních chyb, takže nakonec asi počkám rok a půl na další Debian a teď to hodím jenom na partišnu na hraní.
msk avatar 18.10.2015 10:56 msk | skóre: 27 | blog: msk
Rozbalit Rozbalit vše Re: Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs
V backportoch je 4.1.

Založit nové vláknoNahoru

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