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

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 4
včera 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
včera 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 1
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
20.9. 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
20.9. 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 384 hlasů
 Komentářů: 33, poslední 16.9. 11:55
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: 66 | 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: 12
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: 12
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: 47 | 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: 47 | 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: 47 | 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: 12
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: 47 | 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: 47 | 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: 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.