Příspěvky

31

Server / Re:Btrfs ztratilo část volného místa

« kdy: 07. 06. 2016, 10:45:49 »

Pak pustíš toto a mělo by se to zlepšit. Eventuálně dát do cronu.

Kód: [Vybrat]

btrfs balance start -musage=99 /
btrfs balance start -dusage=99 /

Díky za tip, zkusil jsem se 75 a možná to pomohlo tak o 200 MB. Vypsalo to:

Kód: [Vybrat]

root@web6:~# time btrfs balance start -musage=75 / ; time btrfs balance start -dusage=75 /
Done, had to relocate 5 out of 18 chunks
Done, had to relocate 1 out of 18 chunks

S 99 mám trochu problémy, nejspíš budu muset napřed obětovat nějaký snapshot, aby se uvolnila trocha místa:

Kód: [Vybrat]

ERROR: error during balancing '/' - No space left on device

32

Server / Re:Btrfs ztratilo část volného místa

« kdy: 07. 06. 2016, 10:32:02 »

FreeBSD LUKS nepodporuje a Solaris nejspíš taky ne. Ledaže bys tam připojil rozšifrovanou partitionu

Bohužel nepodporuje. Ano, tu partitionu jsem do VirtualBoxu připojoval rozšifrovanou. Zřejmě jediná možnost.

Neexistuje nějaké multiplatformní šifrování napříč Linux, FreeBSD a příp. Solaris (kromě TrueCrypt/VeraCrypt)?

33

Server / Re:Btrfs ztratilo část volného místa

« kdy: 06. 06. 2016, 02:20:26 »

Na základě čeho si myslíš, že je btrfs production ready?

Dobrá otázka.

Jednak se Btrfs objevilo v instalátoru openSUSE jako defaultní FS na / a pak jsem s Btrfs nikdy nenarazil na žádný problém ovlivňující data a to jsem na Btrfs loni měl 8 TB dat a mám stále jako zálohu disku se ZFS. Akorát má drobné divné chování jako třeba na té zmíněné VPS mi při mých subvolumech:

Kód: [Vybrat]

root@web6:~# btrfs subvolume list /
ID 283 gen 299786 top level 5 path @
ID 285 gen 18548 top level 283 path .snapshots/manual-2016-04-14-1623-very_clear_system
ID 286 gen 18549 top level 283 path .snapshots/manual-2016-04-15-1717-installed_and_configured
ID 287 gen 18550 top level 283 path .snapshots/manual-2016-04-19-0206-first_websites_incl_webman
ID 305 gen 250174 top level 283 path .snapshots/manual-2016-05-18-17-36-all_ok
ID 308 gen 252808 top level 283 path .snapshots/manual-2016-05-20-00-50-all_ok
ID 309 gen 284502 top level 283 path .snapshots/manual-2016-05-31-1725-all_ok

Zobrazuje qgroup show dost divná čísla:

Kód: [Vybrat]

root@web6:~# btrfs qgroup show /
qgroupid rfer                 excl
-------- ----                 ----
0/5      16384                18446744073649876992
0/259    1193369600           0
0/260    1463951360           0
0/272    0                    0
0/273    12769861632          10737438720
0/274    18446744065036468224 0
0/275    18446744065125613568 18446744073709539328
0/276    18446744065125924864 18446744073709543424
0/277    18446744065128497152 18446744073709539328
0/278    18446744066230890496 0
0/279    18446744066230161408 18446744073709539328
0/280    18446744066221613056 0
0/281    18446744066252259328 18446744073569497088
0/282    18446744066447921152 0
0/283    4187918336           1588862976
0/284    18446744066164314112 18446744073709408256
0/285    1193598976           176877568
0/286    1464197120           180932608
0/287    2064633856           316268544
0/288    18446744065077616640 18446744073708093440
0/289    18446744065090887680 18446744073708716032
0/290    18446744065051447296 18446744073684271104
0/291    18446744066179928064 18446744073707323392
0/292    18446744066049306624 18446744073692155904
0/293    18446744066344050688 18446744073707667456
0/294    18446744066315300864 210194432
0/295    18446744066311512064 18446744073709023232
0/296    18446744066059468800 21733376
0/297    0                    0
0/301    3958255616           233730048
0/302    4273758208           346615808
0/303    3581575168           751820800
0/304    2835787776           94531584
0/305    2820542464           245665792
0/308    3297984512           294936576
0/309    3950530560           1256808448

Je tu někdo spokojený s Btrfs, kdo ho alespoň 1 rok bez problémů používá na miliony souborů nebo desítky TB?

34

Server / Re:Btrfs ztratilo část volného místa

« kdy: 06. 06. 2016, 01:55:48 »

Díky za dosavadní cenné odpovědi. Reaguji alespoň v rychlosti:

Souborů a adresářů je dle "find / -xdev | wc" 411128 celkem, což při ztraceném cca 1 GiB by vycházelo ztracených cca 2432 B/soubor. To by smysl dávalo, ale přišlo by mi divné, že df nezapočítá do užitého místa i nevyužité místo souborů. Ok, zapomenu na df (což je škoda).

btrfs fi df

Kód: [Vybrat]

root@web6:~# btrfs filesystem df /
Data, single: total=9.70GiB, used=9.53GiB
System, DUP: total=40.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.60GiB, used=1.05GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=240.00MiB, used=0.00B

A jinak ano, to ZFS mám na "skvělém" 8 TB SMR disku. Ještě k tomu se zapnutou deduplikací. Dokud na něm nebylo moc dat, tak to nevadilo a před použitím jsem bohužel dělal jen sekvenční testy. Díky moc za článek mnohé vysvětlující.

Asi koupím ne-SMR 8 TB disk, provedu bitovou kopii dat na něj a budu doufat, že to dostatečně pomůže. Kdo by chtěl, může si o mém trápení se ZFS přečíst ve vlákně "ZFS pozastavuje zápis po zaplnění bufferu": http://forum.root.cz/index.php?topic=12850.0  Ten jsem "vyřešil" nebo lépe řečeno obešel snížením velikosti zápisového bufferu (echo 4000000 > /sys/module/zfs/parameters/zfs_dirty_data_max). Jenže nedávno mi v journálu uvízlo nedokončené mazání cca 2 GB souboru, které se začne řešit při každém read-write připojení v Linuxu a dříve než se vyřeší, přestane Linux reagovat. Je to ZFS partitiona šifrovaná přes dm-crypt/LUKS, ale i tak se mi ji podařilo zpřístupnit ve VirtualBoxu pro virtualizované FreeBSD a snad i Oracle Solaris, ale obojí odmítlo tu ZFS partitionu připojit (teď nevím proč přesně).

35

Server / Btrfs ztratilo část volného místa

« kdy: 05. 06. 2016, 23:15:04 »

Zdravím,

řeším problém na jedné VPS s Debian 8 na Btrfs, které se mountuje těmito údaji v /etc/fstab:

Kód: [Vybrat]

UUID=824ec9a5-14ec-4df8-a9ec-a685f8903e9d /               btrfs   subvol=@,relatime,compress=zlib,recovery        0       1
UUID=824ec9a5-14ec-4df8-a9ec-a685f8903e9d /mnt/rootfs     btrfs   relatime,compress=zlib,recovery        0       2

A po připojení mount vypisuje:

Kód: [Vybrat]

root@web6:~# mount | grep btrfs
/dev/vda1 on / type btrfs (rw,relatime,compress=zlib,space_cache,subvolid=283,subvol=/@)
/dev/vda1 on /mnt/rootfs type btrfs (rw,relatime,compress=zlib,space_cache,subvolid=5,subvol=/)

Popis problému

Problémem je, že volné místo je o poznání menší než by se očekávalo:

Kód: [Vybrat]

Souborový systém Velikost Užito Volno Uži% Připojeno do
/dev/vda1             11G  9,3G  266M  98% /

11 GB > 9,3 GB + 266 MB

Používám sice subvolumy a snapshotování, ale dle mých zkušeností se při smazání snapshotu sice změní hodnoty u "užito" a "volno", ale nezmění se jejich rozdíl.

Btrfs v3.17, kernel 4.6.0: btrfs scrub

Zkusil jsem scrub, ale ten žádný problém nenašel:

Kód: [Vybrat]

root@web6:~# time btrfs scrub status /
scrub status for 824ec9a5-14ec-4df8-a9ec-a685f8903e9d
        scrub started at Thu May 19 09:57:44 2016 and finished after 21 seconds
        total bytes scrubbed: 8.06GiB with 0 errors

Těch 8.06GiB je méně než v df výpisu, protože jsem mezi tím smazal jeden snapshot. Ještě uvedu verze:

Kód: [Vybrat]

root@web6:~# btrfs version
Btrfs v3.17
root@web6:~# uname -a
Linux web6 4.6.0-040600rc7-generic #201605081830 SMP Sun May 8 22:32:57 UTC 2016 x86_64 GNU/Linux

Btrfs v3.17, kernel 3.16.0: btrfs check

Zkusil jsem boot z live Debian 8 a 2x hned za sebou btrfs check. Obě spuštění vypsaly totéž a problém nevyřešily:

Kód: [Vybrat]

enabling repair mode
Fixed 0 roots.
Checking filesystem on /dev/vda1
UUID: 824ec9a5-14ec-4df8-a9ec-a685f8903e9d
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
checking quota groups
Counts for qgroup id: 5 are different
our:        referenced 3197485056 referenced compressed 3197485056
disk:        referenced 3197485056 referenced compressed 3197485056
our:        exclusive 962273280 exclusive compressed 962273280
disk:        exclusive 902582272 exclusive compressed 902582272
diff:        exclusive 59691008 exclusive compressed 59691008
Counts for qgroup id: 283 are different
our:        referenced 6668357632 referenced compressed 6668357632
disk:        referenced 3244802048 referenced compressed 3244802048
diff:        referenced 3423555584 referenced compressed 3423555584
our:        exclusive 625876992 exclusive compressed 625876992
disk:        exclusive 625876992 exclusive compressed 625876992
Counts for qgroup id: 305 are different
our:        referenced 6244098048 referenced compressed 6244098048
disk:        referenced 2820542464 referenced compressed 2820542464
diff:        referenced 3423555584 referenced compressed 3423555584
our:        exclusive 200433664 exclusive compressed 200433664
disk:        exclusive 200433664 exclusive compressed 200433664
found 4242337340 bytes used err is 0
total csum bytes: 8077580
total tree bytes: 691945472
total fs tree bytes: 631996416
total extent tree bytes: 45137920
btree space waste bytes: 126257397
file data blocks allocated: 111147716608
 referenced 18110992384
Btrfs v3.17
extent buffer leak: start 138199040 len 16384
extent buffer leak: start 244596736 len 16384
extent buffer leak: start 714031104 len 16384
extent buffer leak: start 714620928 len 16384
extent buffer leak: start 716095488 len 16384
extent buffer leak: start 10012327936 len 16384

Na live Debianu jsem měl tyto verze:

Kód: [Vybrat]

root@debian:/mnt# btrfs version
Btrfs v3.17
root@debian:/mnt# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

Btrfs v3.12, kernel 4.6.0: btrfs check

Protože mi verze jádra na live připadala stará, nainstaloval jsem u sebe doma Linux Mint ve VirtualBoxu, v něm doinstaloval Btrfs a aktualizoval jádro, odvážně připojil blokové zařízení disku ve VPS jako lokální přes Network block device (NBD) a zkusil btrfs check. Opět 2x za sebou a opět obě spuštění vypsaly totéž a problém nevyřešily:

Kód: [Vybrat]

enabling repair mode
Checking filesystem on /dev/nbd0
UUID: 824ec9a5-14ec-4df8-a9ec-a685f8903e9d
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 4496713856 bytes used err is 0
total csum bytes: 8077580
total tree bytes: 691945472
total fs tree bytes: 631996416
total extent tree bytes: 45137920
btree space waste bytes: 126258967
file data blocks allocated: 111146471424
 referenced 18109747200
Btrfs v3.12

Pro úplnost opět verze:

Kód: [Vybrat]

krato-VirtualBox ~ # btrfs version
Btrfs v3.12
krato-VirtualBox ~ # uname -a
Linux krato-VirtualBox 4.6.0-040600rc7-generic #201605081830 SMP Sun May 8 22:32:57 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

nospace_cache, clear_cache

S drobným odstupem času a po smazání nějakých snapshotů a vytvoření nových mě ještě napadlo zkusit na VPS mount options nospace_cache a clear_cache, detaily viz https://btrfs.wiki.kernel.org/index.php/Mount_options#Space_cache_control :

Kód: [Vybrat]

krato@web6:~$ mount | grep btrfs
/dev/vda1 on / type btrfs (rw,relatime,compress=zlib,nospace_cache,subvolid=283,subvol=/@)
/dev/vda1 on /mnt/rootfs type btrfs (rw,relatime,compress=zlib,nospace_cache,subvolid=5,subvol=/)

Ale nezdá se, že by to pomohlo, stále je rozdíl cca 1 GB:

Kód: [Vybrat]

krato@web6:~$ df /
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       13619200 12443956    176908  99% /

13619200 = 12443956 + 176908 + 998336 kB

Závěr

Mám na Linuxu problém s částečným zmizením volného místa na Btrfs, které nevyřešil ani btrfs scrub a ani btrfs check.

Chtěl bych začít používat Btrfs všude kde mám nyní ext4, včetně ještě letos plánovaného datového RAID úložiště na více než 10 TB dat. Proto bych se rád naučil tento problém vyřešit jiným způsobem než zkopírovat data jinam, pak Btrfs partitionu znova vytvořit a na konec vrátit data zpět. U jedné VPS s 11 GB to problém není, ale však chápete.

Zkusil jsem nedávno na jednom 8 TB disku ZFS pod Linuxem přes http://zfsonlinux.org/, ale to je jiná kapitola kde jsem měl velké problémy s výkonem a skončilo to tím, že ten disk lze sotva používat read-only. Při připojení read-write se ihned začne přehrávat příliš náročná operace v jornálu mazání cca 2 GB souboru. Ale to tu nechme teď být, dejme teď šanci Btrfs.

Předem děkuji za jakékoliv konstruktivní rady.

36

Server / Re:ZFS pozastavuje zápis po zaplnění bufferu

« kdy: 21. 03. 2016, 03:00:45 »

Řešení

Kód: [Vybrat]

echo 4000000 > /sys/module/zfs/parameters/zfs_dirty_data_max

Sice neřeší rychlost zápisu, ale řeší problém uvedený v předmětu, tj. problém, že "ZFS pozastavuje zápis po zaplnění bufferu". Velikost tohoto "dirty bufferu" je u ZFS on Linux defaultně 10% velikosti fyzické RAM, viz read-only parametr zfs_dirty_data_max_percent. Parametr zfs_dirty_data_max naštěstí přenastavit lze. V mém případě byl defaultně nastaven na 4 GB RAM * 10% = cca 400 MB. Nyní mám přenastaven na 4 MB, které se po zaplnění vyprázdní za cca 4 sekundy. Uvědomuji si kromě výhod i nevýhody, jsou hezky popsané na http://blog.delphix.com/ahl/2014/tuning-openzfs-write-throttle/ , kde jsou navíc uvedeny i další tuningové tipy.

Výběr OS

Snad chápu správně, že pokud od souborového systému chci co nejvíce funkcí a co největší spolehlivost, tak jedinou správnou volbou je ZFS. Nyní řeším na jakém OS ZFS úložiště postavit. Nejvíc narážím na nekompatibilitu šifrování v různých OS. V Linuxu se používá cryptsetup, ve FreeBSD/FreeNAS je to geli a v Oracle Solaris umí šifrovat ZFS samo o sobě, ale jedná se o proprietární řešení. Jenže každá z těchto metod funguje jen v jednom OS, takže po zašifrování ZFS bych už OS nemohl změnit. Nebo se mýlím? Rád bych použil Oracle Solaris, OpenIndiana nebo FreeNAS, ale nejlépe se šifrováním kompatibilním s Linuxem. Možná bych to měl buď zkusit nastudovat sám a nebo zde založit jako nové téma.

37

Server / Re:ZFS pozastavuje zápis po zaplnění bufferu

« kdy: 08. 03. 2016, 13:35:22 »

v RAIDZ2 se můžou bez vlivu na data odmlčet disky dva (aka RAID6) v RAIDZ1 jeden (aka RAID5)

Ok. Hypoteticky: Mám pool s 2 vdev. Každý vdev má 4 disky v RAIDZ2, všechny 4 připojené na jeden zdroj napájení. Na chodu odejde jeden z těch dvou zdrojů, disky zůstávají funkční. Vypnu PC, vyměním zdroj, zapnu PC. Všech 8 disků je stále funkčních. Bude pool opět fungovat nebo jsem přišel o data?

partice jsou potřeba třeba kvůli jiným OS (widle), aby disk nechtěly pořád formátovat a kvůli bios/efi aby z toho mohli bootovat, jestli nepotřebuješ, tak to tam dávat nemusíš, výhoda je, že odpadá kontrola zarovnání partic

Super, thx. Zatím partice vytvářím, zarovnání raději ještě nějak zkontroluji.

podle mě to ZFS nejde takhle rozšiřovat: jeden disk > mirror > raidz2 (to zase jde v btrfs), v zfs budeš muset data zazálohovat a pole znovu vytvořit

Měl jsem na mysli hypoteticky: mám 4 disky v RAIDZ2 vdev. Přidám za rok další 4 disky v RAIDZ2 vdev. A za dva roky dalčí 4 disky v RAIDZ2 vdev. Vím, že vdev nelze rozšiřovat o disky (rozdíl oproti mdadm), ale pool o vdev by jít rozšířit měl, dokonce přidaný vdev může mít libovolnou kapacitu (např. zakoupené větší disky než doposud).

38

Server / Re: ma ty prostoto!

« kdy: 08. 03. 2016, 12:38:56 »

Takze pro zacatek doporucuju zacit jakousi bibli pro dummies )

https://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/

Děkuji za tipy a odkazy. Snad se budou hodit nejen mě.

Stihl jsem si zatím projít prezentaci "FreeNAS Guide" z odkazu výše, ale příliš nových informací jsem se z ní nedozvěděl. Např. nějaké doporučení kolik disků dávat do RAIDZ2 vdev. Zda nepřijdu o data když se v poolu za chodu dočasně odmlčí několik disků najednou (např. výpadek jednoho zdroje napájecího několik disků, ...). Zda použít na ZFS vždy celý fyzický disk a nebo vytvořit MBR/GPT a na tom ZFS partitionu.

Mám si tedy se ZFS hrát na Oracle Solaris nebo FreeBSD (nebo FreeNAS)? Kdybych chtěl mít počítač schopný sloužit jako datové úložiště i jako desktop. Našel jsem, že pro Solaris neexistuje Plex a Chromium a naopak pro FreeBSD existuje VirtualBox jen přes port, také jsem v něm nenašel grub a češtinu kvůli uživatelům, ale mohu se mýlit.

Je lepší šifrovat přes GELI nebo použít šifrování v ZFS (jelikož Solaris 11 umí ZPOOL verze 37)?

Bylo by něco špatného na myšlence nainstalovat Oracle Solaris 11, vytvořit ZPOOL verze 37, zapnout v ZFS šifrování a rozšiřovat pool v budoucnu přidávám paranoidně raději 4 diskových RAIDZ2 vdevů (2+2 redundance)?

39

Server / Re:ZFS pozastavuje zápis po zaplnění bufferu

« kdy: 07. 03. 2016, 23:44:56 »

kde zacat? napriklad tym, ze mas malo RAM.

Vadí u implementace ZFS on Linux, u implementace ZFS-FUSE je pro mé potřeby RAM dostatečná (zápis je plynulý, velký snapshot se smaže), avšak tato implementace je bohužel nestabilní.

ze pouzivas kus softu, ktory nevidel poriadny vyvoj a testovanie poslednych 7 rokov.

ZFS on Linux určitý vývoj má i loni a letos a funkce jsou na úrovni ZFS verze 28. Asi tím máš na mysli fixování málo chyb.

ze ocakavas luxus rolls roycu za cenu trabanta z druhej ruky.

Na to jsem si v Linuxu už celkem zvykl. Včetně Linuxu samotného.

ako plan, preinstaluj na posledny solaris (11.3), pridaj druhy disk, vypni dedup a zapni zrkadlo. potom pridaj RAMku (vela RAMky, kopec RAM). kym nevycerpas moznost pridavat RAM, nepridavaj zbytocne ZIL a L2ARC.

Dedup při zápisu nebo alespoň offline ber jako požadovanou funkci. Jinak bych se rovnou mohl vrátit k Btrfs.

S tím zrcadlem to nechápu. Plánuji celé úložiště v RAID 5 nebo 6 přes mdadm nebo ZFS, ne mirror.

Čemu vadí L2ARC na SSD disku? Neměl by naopak urychlovat čtení?

potom sa vrat, poradime 

Neboj, nikam neodcházím

40

Server / Re:ZFS pozastavuje zápis po zaplnění bufferu

« kdy: 06. 03. 2016, 17:39:53 »

Tak ten dedup pořád nemáš vypnutej?

Kód: [Vybrat]

zpool list| grep dedup

Vono nestačí to jen vypnout, to se vztahuje na nově zapsaný data pouze. Tedy je potřeba vypnout, všechny data zazálohovat, smazat a nahrát znova. Bych zrovna udělal to zfs znova, bez mdadm a se zarovnáním. Stejný to je s kompresí, když přepneš na lz4, tak to platí jen pro nově zapsaná data.

Dedup při zápisu je jedním z hlavních důvodů, proč jsem přešel z Btrfs na ZFS.

Jinak možná blbne hw disku? Stál by za to ho prověřit jednak smartem a pak vlastní zfs

Kód: [Vybrat]

zpool scrub all

Disk byl hned po koupi pro jistotu zkontrolován přes "badblocks -w". Díky za tip na zpool scrub. Je se obávám, že výsledek budu vědět až za několik dní nebo týdnů.

Taky ten disk je dost plnej, není to tím?

To je jeho účel. Potřebuji aby fungoval i plný.

Přemýšlel jsem o návratu k Btrfs, ale nějak mi s ním nefungoval nástroj na deduplikaci (bedup?), která se navíc provádí jen na již uložených datech (na dedup při zápisu se pracuje) a navíc mám strach z nezralosti, viz některé bug fixy a vylepšení teprve v nedávné době, viz https://btrfs.wiki.kernel.org/index.php/Changelog , konkrétně např.:

• btrfs-progs 4.1.2 (Jul 2015): urgent bugfix: mkfs creates invalid filesystem, must be recreated
• v4.2 (Aug 2015): deduplication does not change mtime/ctime

41

Server / Re:ZFS pozastavuje zápis po zaplnění bufferu

« kdy: 06. 03. 2016, 02:10:47 »

Ještě doplním:

Po restartu přeinstalováno zpět na nativní ubuntu-zfs a spuštěno kopírování. To se po cca 470 MB pozastavilo ačkoliv to nevypadá, že by byl nedostatek volné RAM:

Kód: [Vybrat]

top - 02:04:58 up 3 min,  5 users,  load average: 1,77, 0,57, 0,21
Tasks: 914 total,   2 running, 912 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,8 us,  6,9 sy,  0,0 ni, 47,5 id, 44,8 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   4048168 total,  2257116 used,  1791052 free,    83540 buffers
KiB Swap: 16980988 total,        0 used, 16980988 free.  1039824 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                               
 6383 root       1 -19       0      0      0 D   8,5  0,0   0:02.98 z_wr_iss                                                                                              
 6723 root      20   0   25732   2356   1140 R   2,0  0,1   0:00.15 top                                                                                                   
  371 root      20   0       0      0      0 S   1,3  0,0   0:00.44 l2arc_feed                                                                                            
 6681 root      20   0       0      0      0 S   1,0  0,0   0:00.23 kworker/0:3                                                                                           
   61 root      20   0       0      0      0 S   0,3  0,0   0:00.41 kworker/0:2         
...

42

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 06. 03. 2016, 01:46:30 »

Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Děkuji za tip. Každopádně více než rychlost nyní řeším hlavně plynulost zápisu a aby bylo možné mazat snapshoty. Ano, může to spolu souviset.

Aktualizuji informace:

Zjistil jsem, že na ubuntu-zfs (nativní ZFS) cca po 1 dni přestal fungovat OS kvůli OOM aneb došla volná fyzická RAM.

Plynulost zápisu se výrazně zlepšila a nejproblematičtější snapshot se podařilo během 5 hodin smazat potom, co jsem včera odinstaloval ubuntu-zfs (nativní ZFS) a nainstaloval ZFS-FUSE. Akorát zlobí nepochopitelně oprávnění (soubor vlastní uživatel krato, nelze ho otevřít, provedu "chown krato" a už ho lze otevřít), nelze mountovat snapshoty (obchází se klonováním na nový volume) a když jsem se pokusil přihlásit do KDE s domovským adresářem na ZFS, tak ZFS-FUSE dost ošklivě spadl:

Kód: [Vybrat]

rsync: write failed on "/w/videa/cinema-20100908-2000.avi": Software caused connection abort (103)
rsync error: error in file IO (code 11) at receiver.c(389) [receiver=3.1.0]

Kód: [Vybrat]

server ~ # zpool list
connect: Spojení odmítnuto
Please make sure that the zfs-fuse daemon is running.
internal error: failed to initialize ZFS library

Jiné OS jsem zkusil, na doporučení zde FreeBSD a OpenIndiana (nástupce OpenSolaris). FreeBSD mi nesedlo a OpenIndiana zatím ve VirtualBoxu píše při "zpool import" něco o chybném vdev. Nevím, zda to není zmatené tím, že pool byl vytvořen v debian-like Linuxu, tj. s /dev/disk/by-id/<něco> místo /dev/dsk/<něco> atd. Asi to ještě zkusím nativně z Live flash.

Zkusím OpenIndiana nativně, podívám se na velikosti bloků a pak už dál nevím. Na velkou RAM nejsou finanční prostředky a navíc není jistota, že by na plynulost zápisu pomohla.

43

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 20:16:32 »

compression=gzip

Gzip je špatná komprese. Pokud tvoje verze ZFS podporuje něco jiného, použij to v tomhle pořadí:

LZ4 > LZJB > GZIP

Používám ZFS verze 23 kvůli kompatibilitě se ZFS-FUSE kdyby se objevily nějaké vážné problémy se ZFS on Linux. Ta umí LZJB a GZIP, ale neumí LZ4.

LZJB je lepší než GZIP? Jak jsem již uvedl, o rychlost mi moc nejde, proto upřednostňuji efektivitu komprese, která by měla být u GZIP obvykle lepší než u LZJB.

44

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 19:58:34 »

Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s.

Být tebou, řeším vrstvu po vrstvě - prvně rychlost zápisu na holý disk (bez jakéhokoliv FS), potom s další vrstvou, s další vrstvou...

Ok, mohu zkusit zápis náhodných dat na blokové zařízení na kterém je nyní ZFS. Napřed bych zazálohoval třeba 10 GB na jiný disk, přepsal je náhodnými daty a pak původní data vrátil. Tím by se předpokládám nemělo nic stát, když to zařízení nebude používané a dám si pozor na to, co zadávám za parametry. Co zkusit dál pokud zjistím, že ta rychlost je podstatně vyšší a hlavně plynulá?

Mám trochu podezření na to, jestli ti ten LUKS jede přes AES-NI... 1MBps by byl sice dost málo i bez ní, ale jeden z hlavních podezřelých to je.

Jak bych prosím mohl zjistit?

Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.

Pokud ti to opravdu zapisuje rychlostí 1MBps a data tam hrneš rychleji, tak se tohle prostě nevyhnutelně stane, co jiného by se mělo stát? Buffer by bobtnal donekonečna...

Představme si uzavřenou nádrž na vodu, do které velkým jednosměrným horním otvorem vodu přiléváme a druhým malým otvorem dole vytéká. Pokud tuto nádrž naplníme, voda odtékat nepřestane, akorát se nám bude dařit ji přilévat stejnou rychlostí, jakou odtéká. Nestane se, že by najednou vůbec nešla přilévat až do doby, kdy bude nádrž prázdná. Představoval bych si, že data do plného bufferu půjdou přidávat stejnou rychlostí, jakou se z něj zapisují na fyzický disk.

Bojím se mít každý disk šifrovaný zvlášť a až na tom ZFS RAID, protože jednak ZFS RAID moc neumím a pak nevím, zda umí funkce jako mdadm včetně konverze RAID 5 na 6 (resp. RAIDZ na RAIDZ2) nebo dokonce naopak, obzvláště v nativní Linuxové open-source implementaci "ZFS on Linux".

Rozhodně potřebuješ RAID na úrovni ZFS, jinak se zbytečně připravuješ o jeho vlastnosti a zbytečně to kombinuješ s další vrstvou, která nic neví o datech nad ní. Je to špatně a nedělej to tak.

Ok, tuto zkušenost respektuji. Chtěl bych se zeptat, připravuji se o nějaké jiné vlastnosti než jen výkon? A mohu se na RAIDZ a RAIDZ2 spolehnout v Linuxových implementacích "ZFS on Linux" a "ZFS-FUSE"? A umí už ZFS konverzi RAIDZ na RAIDZ2?

Přidávat disky po jednom v ZFS nejde, musíš si buď dopředu připravit scénář, který pro ZFS funguje, nebo se musíš připravit, že v určitém stádiu budeš muset všechna data odlít pryč a vytvořit nový pool.

A právě proto jsem chtěl RAID řešit přes mdadm, aby přidávat disky bylo možné.

Není to nic, co by ses musel kdovíjak učit. Stačí si to prostě vyzkoušet na par loop-devicech...

Děkuji za povzbuzení. Nějak takto jsem se loni trénoval v práci s mdadm RAIDy.

Zvažoval jsem přechod z Linux Mint nebo Debian-based OS obecně na OpenSolaris, ten je ale kvůli Oracle "discontinued". Zvažuji proto přechod na nástupce jménem OpenIndiana, ale byla by to celkem velká změna a nevím, jak moc kvalitní je implementace ZFS v OpenIndiana.

Určitě o několik řádů kvalitnější než na Linuxu

Takže předpokládám správně, že implementace ZFS v OpenIndiana vychází z implementace v OpenSolaris? Funguje na OpenIndiana hardware bez problémů a lze doinstalovat KDE či xfce? Vyvíjí se vůbec aktivně OpenIndiana?

Nicméně pokud se ti nechce do Solarisích klonů, na FreeBSD už je ZFS mnoho let a je už slušně vychytané.

Aha, to je dobré vědět, děkuji. Jen na tom nechápu: Myslel jsem, že Linux je rozšířenější než FreeBSD či OpenIndiana, tj. software by měl být pro Linux obecně lépe odladěný. Je to jinak?

Mám sice jen 4 GB RAM

NO WAY!

Why? Snížení rychlosti bych chápal, ale vážné narušení plynulosti zápisu moc nechápu.

A general rule of thumb is 1 GB of RAM for every 1 TB of storage. If the deduplication feature is used, a general rule of thumb is 5 GB of RAM per TB of storage to be deduplicated.

https://www.freebsd.org/doc/handbook/zfs-advanced.html

...čili máš desetkrát míň RAM než je na tolik dat doporučeno.

...čili mám desetkrát míň RAM než je na tolik dat doporučeno. Chápu tím vysvětlení zápisu 1 MB/s, ale ne problémů s plynulostí.

, ale swap 16 GB je téměř vždy prázdný.

Se swapem to imho nemá co dělat.

L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:

L2ARC je read cache, která se použije jenom v případě, že čteš data, která nejsou nacachovaná v RAM. Pokud z poolu nečteš, nepoužije se ani 1B L2ARC Takže s tvými problémy se zápisem to nijak nesouvisí.

Hashe používané při deduplikaci se při čtení nijak necachují? Dokáži si představit situace, kdy by se to hodilo.

45

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 17:28:15 »

Není to disk který byl podezřele levný kvůli tomu že používá SMR (shingled magnetic recording)? Zápis na takové disky prostě je po zaplnění jejich cache pomalý a nedá se s tím nic dělat, za to ZFS nemůže...

Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s. Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.