Omezení velikosti ext4 aneb od mdraid + LVM + ext4 k Btrfs (diskuse)

[Ruda]

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]

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.

[pavele]

A už jsi ten výpadek disku zkoušel nasimulovat? Myslím, že Heron měl k tomu kdysi nějakou řeč.

[Cohen]

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.

[Heron]

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]

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

[Heron]

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]

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.

[Heron]

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]

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]

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

[Pavel Píša]

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.

[R]

Pri klasickom RAIDe 1 sa data na disku, ktory je neaktualny (bol vyradeny z pola z lubovolneho dovodu), musia prepisat aktualnymi datami.

[Pavel Píša]

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         -

[R]

mdraid podporuje write-intent bitmapu - ta umoznuje urobit ciastocny resync po vybrati/vlozeni disku (aktualizuju sa len zmenene bloky).

[Aleš Kapica]

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ěží..

[Aleš Kapica]

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..

[Aleš Kapica]

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.

[Pavel Píša]

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]

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.

[Aleš Kapica]

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ý"?

[Ruda]

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]

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á.

[trekker.dk]

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.

[Heron]

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.)

[trekker.dk]

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.

[Heron]

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.)

[Aleš Kapica]

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®]

Ony ještě dělaj? Obchoďák z PCV Comp mi řikal, že kromě velký dvojky disky dělá už jen Toshiba...

[Cohen]

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).

[=^..^= AmigaPower®]

s 2.5 diskem Toshiba mám podobnou zkušenost, vlastně bych to s těma diskama viděl asi tak "naprosto stejně"

[00000]

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]

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ů.

[Heron]

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).

[kolcon]

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]

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ě?

[kolcon]

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]

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.

[kolcon]

tak nakonec jsem mirne poupravil debiani "standardni" initramfs...

[kolcon]

jen pro zaznam - nakonec to debiani initram zvladne sam, staci mit spravne /etc/crypttab

[Jenda]

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]

V backportoch je 4.1.