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 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 1
včera 23:55 | Komunita

Společnost Librem na svém blogu oznámila, že jejich notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 1
včera 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 0
včera 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 4
včera 13:00 | Komunita

MojeFedora.cz informuje, že Fedora 27 dostane podporu pro AAC. Podpora multimediálních formátů je ve výchozí instalaci Fedory tradičně limitovaná kvůli softwarovým patentům, ale desktopový tým Red Hatu se ji i tak snaží v poslední době co nejvíce rozšířit. Už nějaký čas obsahuje kodeky pro MP3, H.264, AC3 a nyní byl přidán také kodek pro další velmi rozšířený zvukový formát – AAC.

Ladislav Hagara | Komentářů: 2
18.10. 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
18.10. 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 2
18.10. 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
18.10. 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (11%)
 (1%)
 (1%)
 (1%)
 (74%)
 (12%)
Celkem 107 hlasů
 Komentářů: 7, poslední včera 23:06
    Rozcestník
    Štítky: není přiřazen žádný štítek

    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: 51 | 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: 51 | 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: 51 | 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: 65 | 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: 11
    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: 11
    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: 46 | 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: 46 | 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: 46 | 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: 11
    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: 46 | 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: 51 | 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: 51 | 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: 51 | 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: 46 | 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.
    ✭Ⓜ♪☭✯⚑☢ⓦ€☈ avatar 5.10.2015 20:03 ✭Ⓜ♪☭✯⚑☢ⓦ€☈ | 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...
    I♥DRX * Děte do píči s poníkama!   -->   www.KERNELULTRAS.org     devonrex@jabber.ccc.de
    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/)
    ✭Ⓜ♪☭✯⚑☢ⓦ€☈ avatar 5.10.2015 20:42 ✭Ⓜ♪☭✯⚑☢ⓦ€☈ | 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
    I♥DRX * Děte do píči s poníkama!   -->   www.KERNELULTRAS.org     devonrex@jabber.ccc.de
    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: 51 | 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: 51 | 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

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

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