Názory k článku Linuxové jádro 5.12 přinese rychlejší Btrfs a podporu Ryzenů 5000
-
Peter FodrekZlatý podporovatel>Phoronix připomíná, že pro Ryzeny stále není k dispozici pořádné měření
>energie/spotřeby, protože ovladač AMD_Energy je omezen pouze na
>produkty řady EPYC a potřebný kód ze standardního ovladače byl s jádrem
>Linux 5.11 vyhozen pro nedostatečnou dokumentaci a následné věci.Sú následné veci sú to, že ten kód by predstavoval navýšenie podielu AMD na zmenách v jadare 5.11. o 10,4%?
Development statistics for the 5.11 kernel
[LWN subscriber-only content]Most active 5.11 employers
By lines changed
1.AMD 382664 39.7%
2.Intel 94102 9.8%
3. Linaro 47288 4.9%
https://lwn.net/Articles/845831/ -
Nie, pretože ten ovládač nerobilo AMD.
Robili ho vývojári tretích strán, a to bez akejkoľvek dokumentácie, iba systémom funguje to na mojom počítači. No a potom zistíš, že na inom modeli musíš použiť iné konštanty (niečo ako je temperature offset na threadripperoch), inak to aj tak ukazuje hlúposti. Tak sa rozhodli, že to nemá zmysel, kým nebude dokumentácia.
-
Peter FodrekZlatý podporovatel
Jaj to sa nerobí inštrukciami RDNA2, lebo tam je dokumentácia verejná
AMD Publishes RDNA 2 ISA Documentation
on 9 December 2020
https://www.phoronix.com/scan.php?page=news_item&px=AMD-RDNA2-ISA-Documentation
https://gpuopen.com/rdna2-isa-available/A právnici AMd to skontroloval ina potenciálne cudzie patenty za rekordných 19 dní..ň
"RDNA 2" Instruction Set ArchitectureReference Guide
AMD
30-November-2020
https://developer.amd.com/wp-content/resources/RDNA2_Shader_ISA_November2020.pdf -
Podpora Ryzenu 5000 kdyz laptopy s Ryzen 4000 ani jeste nezvladnou S0ix sleep states? Vyrobce ve firmwaru nepodporuje klasicke Sx stavy, notebook proste na Linuxu neuspite a kdyz se o to pokusite, musite restartovat. Problemy maji vsichni vyrobci - Dell, HP, Asus, ale i Xiaomi, ale AMD na "reference board" pry vsechno funguje...
-
Dobré zprávy, ale co se týká Btrfs, uvítal bych spíše zvyšování odolnosti vůči fatálnímu selhání. Dokud toto nebude pořešené např. při nasazení v NAS nebo v běžném PC, rozhodně bych do tohoto fs při instalaci nešel (i přes mnoho nesporných výhod). Jiná situace může být na 24/7 serverech, kde nehrozí výpadek napájení a zdraví disků je pod trvalou kontrolou...
-
Já mám Btrfs len pár mesiacov. Tiež SATA SSD ale už vážne začínam uvažovať nad zmenou filesystému. Bežne sa mi stáva, že systém alebo aplikácia (napr. browser) na niekoľko sekúnd (5-10) zatuhne a nie je možné nič robiť. Top zobrazuje, že buď btrfs-transacti alebo btrfs-cleaner vyťažujú procesor na 100%. Dosť ma to zaskočilo, lebo tam mám AMD Ryzen 5 3500X s 16GB RAM. Mám tam Mint 20.1, distribučný kernel z Ubuntu 20.04 5.8.0-43-generic. Skúšal som update na kernel 5.11 z https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11/. Žiaľ potom sa mi zo suspendu neprebrala grafika a musel som reštartovať. Vy takéto problémy neregistrujete? Alebo mám len niečo blbo nastavené?
19. 2. 2021, 15:24 editováno autorem komentáře
-
BTRFS používám už od dob experimentální verze. Tak před deseti lety skutečně k nějaké ztrátě dat dojít mohlo. Ale cca 7 let zpět jsem nezaznamenal žádný problém.FS funguje velmi dobře a spolehlivě. Mám ho na dvaceti discích v různých počítačích a v žádném případě nedochází k nějakým zámrzům nebo vysokému vytížení CPU nástrojem pro BTRFS. Osobně vřele doporučuji. Ovšem proč Vám to zlobí, pokud jsou problémy skutečně způsobeny nástroji pro BTRFS, to těžko říct. Kouknul bych ještě na SMART disku. Tam může být taky zakopaný pes.
-
Samsung 860 EVO 250GB, píšu pri ňom MLC. Snáď je to pravda. Disk je zaplnený na 27%, swap je na samostatnej partícií, mimo btrfs.
mlady@desktopwork:~$ btrfs filesystem df / Data, single: total=58.01GiB, used=53.57GiB System, single: total=4.00MiB, used=16.00KiB Metadata, single: total=9.01GiB, used=1.93GiB GlobalReserve, single: total=168.55MiB, used=0.00B mlady@desktopwork:~$ sudo fdisk -l /dev/sda Disk /dev/sda: 232,91 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 860 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: ED0FAF67-118F-40E1-BF67-ED56AF9C962E Device Start End Sectors Size Type /dev/sda1 2048 1050623 1048576 512M EFI System /dev/sda2 1050624 455423999 454373376 216,7G Linux filesystem /dev/sda3 455424000 488396799 32972800 15,7G Linux swap
-
No, to jsou holt mrchy ze Samsungu a jejich "3bit MLC" blábol. 3bit MLC je prostě TLC. Mám také TLC SSD, typicky tyhle levný SSDčka mají určitou "SLC cache" v řádu jednotek GB. u Mého 240GB SSD je to cca 4GB cache. Jakmile na SSD hrnu v jedné dávce víc než 4GB, tak se to TOTÁLNĚ ZASEKÁ nezávisle na filesystému a musíš počkat, než si to SSD ty data z cache přechroustá do TLC buněk. Je to vlastně podobný jako SMR u HDD. U mě to může v závislosti na to, kolik tam toho rvu naráz, trvat i více než 10min, po které je počítač de facto nepoužitelný.
Takže tl;dr: vítej ve světě TLC.
-
V tom to asi nebude. 20GB video som nemal. Na HDD som si preto skombinoval niekoľko video súborov do jedného cez cat. Vznikol 28GB file. Ten som potom kopíroval na SSD. Žiadne mrznutie sa nedialo a kopírovalo to stabilnou rýchlosťou (na začiatku trochu rýchlejšie):
mlady@desktopwork:/mnt/backups/Fotky$ time rsync --progress /mnt/backups/tmp/kombinovanevidea.xyz /home/mlady/ kombinovanevidea.xyz 29,687,160,922 100% 175.53MB/s 0:02:41 (xfr#1, to-chk=0/1) real 2m41,348s user 1m25,555s sys 0m22,716s
Ak tomu správne rozumiem, tak to presypanie dát z cache do TLC buniek je záležitosť disku, takže OS s tým nič nemá. Ale mne keď dôjde k zmrznutiu, tak tam sú procesy btrfs-transacti alebo btrfs-cleaner a berú 100% CPU + nejaké IO (hodnotu si nepamätám).
-
k3dARStříbrný podporovatels WD Blue 3D NAND (~3D TLC) NEpozoruju zadne zaseky ani pri vetsich souborech ;-) Samsungu se vyhejbam (pred WD Blue sem pouzival Transcend MLC) od pocatku, ale marketing maj "dobrej" :-)
-
A ešte jedna poznámka: nedeje sa to pri nejakom masivnom zápise dát. Bežné browsovanie, niečo hľadám na webe alebo odpisujem na email a zrazu na pár sekúnd stuhne. Eventy sa ukladajú do buffera, takže potom zrazu bleskovo dopíše slovo, otvorí nový tab a pod. podľa toho, čo som sa snažil urobiť pred zatuhnutim.
-
Ja som mal svojho času podobny efekt pri trimovani na Intel SSD 520 series, bez ohľadu na filesystém. Vtedy to bolo dosť nešťastnou implementáciou trimu v týchto diskoch a minimalizoval som to tak, že som vypol discard option v /etc/fstab a nechal to na fstrim.service tak raz za týždeň.
Na Samsungoch som sa s tým nestretol. Dnes mám na 860 EVO LVM, z ktorého ukusujem jednotlivé LV pre virtuálky, mnohé z nich majú btrfs a všetko ide tak, ako má. (a host je default inštalácia Fedory 33 na btrfs, na 960 EVO).
-
Vyskúšal som a budem sledovať ako sa to správa. Tiež mi napadlo, či nie je problém v nesprávnom rozdelení na subvolumes a následnými snapshotmi. Momentálne mám iba dve subvolume - @ pre / a @home pre /home. Snapshoty vytvára automaticky timeshift, hlavne pri práci s apt (timeshift-autosnap-apt). Možno je problém v tom, že na tých snapshotoch sú data, ktoré sa často menia (cache a pod.) a po ich zmene/vymazaní musí btrfs veľa upratovať. Mohli by ste mi poslať rozdelenie subvolume u vás? V /etc/fstab mám toto:
UUID=e9dc761d-68e1-455a-ad6b-26537b2e0f9b / btrfs defaults,subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd 0 1 UUID=e9dc761d-68e1-455a-ad6b-26537b2e0f9b /home btrfs defaults,subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd 0 2
A snapshoty vyzerajú takto:
root@desktopwork:~# btrfs subvolume list / ID 256 gen 21253 top level 5 path @ ID 257 gen 21253 top level 5 path @home ID 280 gen 20596 top level 5 path timeshift-btrfs/snapshots/2020-12-15_19-33-30/@ ID 281 gen 2089 top level 5 path timeshift-btrfs/snapshots/2020-12-15_19-33-30/@home ID 500 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-01-16_15-00-01/@ ID 501 gen 11339 top level 5 path timeshift-btrfs/snapshots/2021-01-16_15-00-01/@home ID 603 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-05_11-00-01/@ ID 604 gen 17192 top level 5 path timeshift-btrfs/snapshots/2021-02-05_11-00-01/@home ID 633 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-12_12-00-02/@ ID 634 gen 19097 top level 5 path timeshift-btrfs/snapshots/2021-02-12_12-00-02/@home ID 643 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-15_10-00-01/@ ID 644 gen 19494 top level 5 path timeshift-btrfs/snapshots/2021-02-15_10-00-01/@home ID 647 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-16_13-00-01/@ ID 648 gen 19871 top level 5 path timeshift-btrfs/snapshots/2021-02-16_13-00-01/@home ID 651 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-16_15-00-01/@ ID 652 gen 19942 top level 5 path timeshift-btrfs/snapshots/2021-02-16_15-00-01/@home ID 653 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-17_14-00-01/@ ID 654 gen 20072 top level 5 path timeshift-btrfs/snapshots/2021-02-17_14-00-01/@home ID 663 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-18_14-00-02/@ ID 664 gen 20332 top level 5 path timeshift-btrfs/snapshots/2021-02-18_14-00-02/@home ID 669 gen 20596 top level 5 path timeshift-btrfs/snapshots/2021-02-19_15-00-01/@ ID 670 gen 20566 top level 5 path timeshift-btrfs/snapshots/2021-02-19_15-00-01/@home ID 675 gen 20601 top level 5 path timeshift-btrfs/snapshots/2021-02-19_15-40-18/@ ID 677 gen 21165 top level 257 path @home/.snapshots ID 678 gen 21170 top level 5 path timeshift-btrfs/snapshots/2021-02-20_11-09-15/@ ID 679 gen 21170 top level 5 path timeshift-btrfs/snapshots/2021-02-20_11-09-15/@home ID 680 gen 21177 top level 5 path timeshift-btrfs/snapshots/2021-02-20_11-17-25/@ ID 681 gen 21177 top level 5 path timeshift-btrfs/snapshots/2021-02-20_11-17-25/@home ID 682 gen 21220 top level 5 path timeshift-btrfs/snapshots/2021-02-20_12-31-59/@ ID 683 gen 21220 top level 5 path timeshift-btrfs/snapshots/2021-02-20_12-31-59/@home
-
Jak je ctěná libost. Tady je kopírování mezi dvěma oddíly na stejném disku těsně po startu počítače.
$ /home/virtual/testy $ ls -lh celkem 52G -rw-r--r-- 1 root root 38G 28. led 23.36 exchg2016.qcow2 drwxr-xr-x 1 root root 270 31. led 17.08 lxc -rw-r--r-- 1 root root 16G 16. úno 16.01 xenmanage.qcow2 $ /home/virtual/testy $ time bash -c 'rsync --progress *.qcow2 /home/username/tmp/test/; sync' exchg2016.qcow2 40,630,222,848 100% 365.63MB/s 0:01:45 (xfr#1, to-chk=1/2) xenmanage.qcow2 17,066,491,904 100% 339.43MB/s 0:00:47 (xfr#2, to-chk=0/2) real 2m34,846s user 2m43,458s sys 0m34,182s
Notebook ASUS UX325EA, CPU i7-1165G7, 16GB RAM, Corsair Force MP510 1.92TB. Na zdrojovém i cílovém oddílu je BTRFS nad LVM2 nad LUKS2. Podobnou rychlost totéž SSD dávalo i na předchozím notebooku s dvoujádrovým procesorem o pár generací starším. Je teda fakt, že na dvouterovém SSDčku je velikost cache trošku někde jinde než na dvěstěpadesátce...
20. 2. 2021, 16:37 editováno autorem komentáře
-
PS: ještě čistě zápis. Nemám tu dostatečně rychlý zdroj, abych mohla zjistit jak je to při kopírování mezi dvěma disky, ale vzhledem k tomu, že podklad je šifrovaný, mělo by se zapsat 50GB šumu i takhle:
~ $ time bash -c 'dd if=/dev/zero of=test.bin bs=10M count=5000; sync' 5000+0 záznamů přečteno 5000+0 záznamů zapsáno 52428800000 bajtů (52 GB, 49 GiB) zkopírováno, 50,0618 s, 1,0 GB/s real 0m54,880s user 0m0,019s sys 0m17,206s
Je fakt, že při téhle rychlosti ten počítač už během zápisu na pár sekund opravdu přestal reagovat. Jestli je to filesystemem nebo SSD cachí nemám tušení...
-
Stejný problém má více uživatelů https://forums.opensuse.org/showthread.php/533829-Computer-frozen-by-btrfs-cleaner-amp-btrfs-transacti-using-100-CPU
-
Možná předřečník myslel něco, co by nahradilo ZFS na Linuxu. Ale bohužel, btrfs mi nepřijde, že by mělo takové ambice :-/.
To je asi důvod, proč všichni lejou energii do toho, aby ZFS na Linuxu jelo a čím dál tím více komerčních firem přecházejí z BSD+ZFS na Linux+ZFS.
Třeba takový QNAP vypadá, že je to jeho cesta, to samé TrueNAS a je to vidět i jinde.
Zdar Max
