Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Témata - Petr Kratochvíl

Stran: [1]
1
Server / Záchrana Btrfs volume poškozeného při btrfs check
« kdy: 12. 05. 2022, 01:12:35 »
Zdravím,

prosím o záchranu reputace Btrfs a jako vedlejší efekt i 5,28 TiB mých záloh. Volume vykazoval problémy a po spuštění a pádu btrfs check už nejde ani připojit. Popíši to celé chronologicky níže.

Popis

Měl jsem Linux openSUSE Leap 15.3 s jen oficiálními repozitáři. Byl ve VPS na QNAP NAS.

Do něj jsem měl z toho NASu přes ISCSI připojený 5,28 TiB volume obsahující zálohy všech mých serverů na šifrovaném Btrfs. Říkejme mu třeba blokové zařízení /dev/star1/backups:

Kód: [Vybrat]
localhost:~ # blockdev --getsize64 /dev/star1/backups
5798201655296

localhost:~ # blkid /dev/star1/backups
/dev/star1/backups: LABEL="space-backups" UUID="18d0fd43-c0ac-42f6-a480-fb4f02932b00" UUID_SUB="f91d3e0c-46a6-4ab4-b492-1ed211a1d030" BLOCK_SIZE="4096" TYPE="btrfs"

Protože se mi tento Btrfs volume začal přepínat vždy chvíli po bootu do read-only kvůli nějakému problému, spustil jsem na něm btrfs check, ten ale spadl:

Kód: [Vybrat]
krato-nas01-vps-backups:/home/krato # date ; time btrfs check --repair --clear-space-cache v1 --progress --check-data-csum /dev/star1/backups ; date
Mon May  9 17:03:49 CEST 2022
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/star1/backups
UUID: 18d0fd43-c0ac-42f6-a480-fb4f02932b00
Failed to find [6147432235008, 168, 16384]
btrfs unable to find ref byte nr 6147432251392 parent 0 root 2  owner 0 offset 0
transaction.c:195: btrfs_commit_transaction: BUG_ON `ret` triggered, value -5
btrfs(+0x51f99)[0x55a7695aef99]
btrfs(btrfs_commit_transaction+0x1ae)[0x55a7695af58e]
btrfs(btrfs_clear_free_space_cache+0xdc)[0x55a7695a20bc]
btrfs(+0x157fa)[0x55a7695727fa]
btrfs(cmd_check+0x103a)[0x55a7695c4cca]
btrfs(main+0x8e)[0x55a76957c08e]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7febe47e034d]
btrfs(_start+0x2a)[0x55a76957c28a]
Aborted (core dumped)

Po jeho pádu oddíl najednou už ani nešel připojit:

Kód: [Vybrat]
localhost:~ # mount /dev/star1/backups /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/star1-backups, missing codepage or helper program, or other error.

localhost:~ # dmesg -T | tail
[Wed May 11 20:32:53 2022] BTRFS error (device dm-1): open_ctree failed
[Wed May 11 21:25:42 2022] hrtimer: interrupt took 18596350 ns
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): flagging fs with big metadata feature
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): disk space caching is enabled
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): has skinny extents
[Thu May 12 00:17:06 2022] BTRFS info (device dm-1): bdev /dev/mapper/star1-backups errs: wr 1, rd 0, flush 0, corrupt 408, gen 0
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): failed to read block groups: -5
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): open_ctree failed

Protože btrfs check při dalších pokusech opět vždy spadl, nainstaloval jsem novou VPS s openSUSE Tumbleweed, kernel upgradoval na 5.18-rc6 a blokové ISCSI zařízení připojil jen do této VPS:

Kód: [Vybrat]
localhost:~ # head -n 2 /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20220507"

localhost:~ # uname -a
Linux localhost.localdomain 5.18.0-rc6-1.ged50f8f-default #1 SMP PREEMPT_DYNAMIC Sun May 8 21:14:22 UTC 2022 (ed50f8f) x86_64 x86_64 x86_64 GNU/Linux

localhost:~ # btrfs --version
btrfs-progs v5.17

Na něm btrfs check napíše nějaké chyby a pak to vzdá:

Kód: [Vybrat]
localhost:~ # btrfs check /dev/star1/backups
Opening filesystem to check...
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=6086151536640 item=223 parent level=1 child bytenr=6086151716864 child level=1
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

Zkusil jsem btrfs rescue zero-log a btrfs rescue clear-uuid-tree, ale nepomohlo to.

Zkusil jsem na konec ještě btrfs rescue chunk-recover, ale to se vždy po pár hodiných přeruší s chybovou hláškou:

Kód: [Vybrat]
localhost:~ # date ; time btrfs rescue chunk-recover /dev/star1/backups ; date
Wed May 11 20:35:04 CEST 2022
Scanning: 272670670848 in dev0scan chunk headers error
Chunk tree recovery aborted

real    140m45.289s
user    4m31.873s
sys     25m25.405s
Wed May 11 22:55:49 CEST 2022

Připadá mi, že se to neustále točí dokola jen kolem následující chybové hlášky. Možná je tam jen jeden zádrhel, se kterým si neumí poradit mount a ani check. Tato chyba myslím byla také v dmesg úplně na začátku kdy ještě šel ten oddíl přimountovat a přepnul se po chvíli do read-only:

Kód: [Vybrat]
parent transid verify failed on 6086151716864 wanted 487495 found 487500

Dotaz

Máte někdo prosím nějaký nápad jak to opravit aby to šlo opět přimountovat a číst data?

Jedná se v mém případě "jen" o tisíce záloh různých strojů. Cítím to hlavně jako velkou zkoušku vyspělosti Btrfs. Protože jestli "načatý" Btrfs dokáže "btrfs check" dorozbít, že to už nic neopraví a to na stable Linuxu a kernelu, tak se začnu bát můj velmi oblíbený Btrfs používat kdekoliv.

Mohu vyzkoušet jakoukoliv Vaši radu, ten oddíl jsem právě teď snapshotnul. Bohužel naivně ne už před btrfs check. Teď mi stejně jde hlavně o to, zda se lze na Btrfs spolehnout.

2
Ahoj všichni,

předem díky za jakoukoliv konstruktivní radu, došly mi nápady.

Úvod

Mám 7 disků, každý z nich 8 TB s jedním velkým oddílem /dev/sd[bcdijkl]1, vytvářející přes mdadm RAID 6 jedno blokové zařízení /dev/md0 velké 40007 GB. Na celém /dev/md0 jsou data šifrovaná přes dm-crypt/LUKS, na kterém je LVM a na něm cca 20 oddílů ext4 a Btrfs, ale to je teď vedlejší, protože problém nastává již před připojením šifrovaného oddílu, tj. před provedením cryptsetup luksOpen /dev/md0 <dm_name>.

Stručný popis

Občas se čtou z mdadm RAID 6 pole /dev/md0 náhodná data, při současném zápisu se čtou velmi často náhodná data. Čtení z jednotlivých disků čte vždy stejná data, nikdy náhodná. Dle mdadm check je pole v pořádku.

Experiment č. 1: čtení z /dev/md0

Pokud zkusím číst opakovaně stejných 10 GiB z /dev/md0 od offsetu 1 TiB, mají data dle očekávání vždy stejný md5 checksum:

Kód: [Vybrat]
root@krato-space:~# for DEV in md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..6} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum )
; done ) ; done ; date
==== md0 ====
Po lis 26 12:13:26 CET 2018
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
Po lis 26 12:16:03 CET 2018

Experiment č. 2: čtení z /dev/md0

Občas je oproti očekávání ne vždy stejný md5 checksum (viz poslední):

Kód: [Vybrat]
root@krato-space:~# for DEV in md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..4} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum ) ; done ) ; done ; date
==== md0 ====
Po lis 26 22:20:25 CET 2018
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
03247245c2a9920f6acc2ce7ce51ad92  -
1e434d76b388b0c21dec709a6d1b6d20  -
Po lis 26 22:22:08 CET 2018

Experiment č. 3: čtení z /dev/md0 při zápisu

A teď pozor. Pokud při čtení zároveň probíhá jakýkoliv zápis na jiném místě pole, přečtu z /dev/md0 občas nebo pokaždé data s jiným checksumem.

Říkám si, že mi leží těch 7 SATA kabelů volně uvnitř i vně case (disky leží vedle case, dovnitř se už nevešly), tak zda nechytají nějaké rušení nebo nezlobí některý ze dvou SATA řadičů, jenže pokud čtu data z disků zvlášť, je checksum vždy v pořádku. První a poslední čtveřice jsou checksumy 10 GiB čtených z /dev/md0, sedm čtveřic mezi nimi jsou čtení z jednotlivých disků:

Kód: [Vybrat]
root@krato-space:~# for DEV in md0 sdb1 sdc1 sdd1 sdi1 sdj1 sdk1 sdl1 md0 ; do ( echo "==== $DEV ====" ; date ; for i in {1..4} ; do ( dd if=/dev/$DEV bs=1M count=10240 skip=1048576 status=none | md5sum ) ; done ) ; done ; date
==== md0 ====
Po lis 26 20:03:03 CET 2018
31a877f49150e0f6452b843d81a8c88d  -
9b2010d3fb1344139f9eba21ad309b7b  -
e11e03afc313e5de46105f15ffc33665  -
9bfde541773fc0ef03a4b1ff1c45621c  -
==== sdb1 ====
Po lis 26 20:08:15 CET 2018
7fdc1658562a2ecd4d676bf656c973a7  -
7fdc1658562a2ecd4d676bf656c973a7  -
7fdc1658562a2ecd4d676bf656c973a7  -
7fdc1658562a2ecd4d676bf656c973a7  -
==== sdc1 ====
Po lis 26 20:26:35 CET 2018
7c671e9e47fdb2604e2ecfcea6009218  -
7c671e9e47fdb2604e2ecfcea6009218  -
7c671e9e47fdb2604e2ecfcea6009218  -
7c671e9e47fdb2604e2ecfcea6009218  -
==== sdd1 ====
Po lis 26 20:45:38 CET 2018
bb14e932be6c2ae2751404a997c24712  -
bb14e932be6c2ae2751404a997c24712  -
bb14e932be6c2ae2751404a997c24712  -
bb14e932be6c2ae2751404a997c24712  -
==== sdi1 ====
Po lis 26 20:56:27 CET 2018
4fb8ad4d063fff30e39ff64205713952  -
4fb8ad4d063fff30e39ff64205713952  -
4fb8ad4d063fff30e39ff64205713952  -
4fb8ad4d063fff30e39ff64205713952  -
==== sdj1 ====
Po lis 26 21:07:44 CET 2018
00528ce93f8c54882d022f976004442f  -
00528ce93f8c54882d022f976004442f  -
00528ce93f8c54882d022f976004442f  -
00528ce93f8c54882d022f976004442f  -
==== sdk1 ====
Po lis 26 21:38:04 CET 2018
33d73ace82b8bc28fd284fc32c216039  -
33d73ace82b8bc28fd284fc32c216039  -
33d73ace82b8bc28fd284fc32c216039  -
33d73ace82b8bc28fd284fc32c216039  -
==== sdl1 ====
Po lis 26 21:45:57 CET 2018
842b476f2973e16403f3fc1a031b968a  -
842b476f2973e16403f3fc1a031b968a  -
842b476f2973e16403f3fc1a031b968a  -
842b476f2973e16403f3fc1a031b968a  -
==== md0 ====
Po lis 26 21:53:30 CET 2018
e08baf910b005f1f001c8258330a0637  -
4ce735569e51ad0e75d4775a0a2e565b  -
d740da3b4b7a2167ca369c9b00efe6d2  -
75f0c751bbd8f95b0ed6d49c379f9ff8  -
Po lis 26 22:06:22 CET 2018

Konkrétně u tohoto experimentu č. 3 jsem prováděl zápis tím způsobem, že jsem na jiném offsetu 1 GiB načetl 100 GiB dat do souboru na systémovém SSD disku:

Kód: [Vybrat]
dd if=/dev/md0 bs=1M count=102400 skip=1024 status=progress of=/root/md0_offset-1024M_size-102400M-2018-11-26-1308.bin

A tato data jsem pak při testu čtení v cyklu zapisoval zpět přesně tam, odkud jsem je přečetl:

Kód: [Vybrat]
for i in {1..10} ; do dd if=/root/md0_offset-1024M_size-102400M-2018-11-26-1308.bin bs=1M count=102400 seek=1024 status=progress of=/dev/md0 ; done

Chyba software vs. hardware

Nezkouším koupit nový hardware (kabely, case, zdroj, disky, ...), protože při čtení z jednotlivých disků zvlášť nikdy tento problém nepozoruji.

Vyloučení nekonzistence dat RAID 6

Už se určitě chystáte poradit mdadm check a mdadm resync. To by to ale bylo příliš jednoduché.

Před testy výše jsem provedl postupně:

  • mdadm resync ... našel 3688 chyb (dle čísla v /sys/block/md0/md/mismatch_cnt)
  • mdadm check ... našel 0 chyb (dle čísla v /sys/block/md0/md/mismatch_cnt)

Verze software


root@krato-space:~# lsb_release --description
Description:    Ubuntu 18.04.1 LTS

root@krato-space:~# uname --all
Linux krato-space 4.19.2-041902-generic #201811132032 SMP Tue Nov 13 20:34:19 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

root@krato-space:~# mdadm --version
mdadm - v4.1-rc1 - 2018-03-22

3
Server / Unmountable btrfs: bad tree block start
« kdy: 17. 10. 2018, 20:02:37 »
Zdravím,

nenapadne prosím někoho nějaká rada jak zkusit zachránit data?

Mám 40 TB Btrfs (obsazeno 32 TB) šifrované přes dm-crypt/LUKS ležící na diskovém poli mdadm RAID 6. Používám kompresi zstd, zapnuté datacow a checksum a mám tyto verze software (měly by být aktuální): OS Xubuntu 18.04.1 LTS, kernel 4.18.14-041814-generic, btrfs-progs 4.17

Prováděl jsem několik btrfs receive a mazal pár desítek subvolumes (je jich tam cca 800), když v tom jsem si všiml, že jeden subvolume nejde otevřít (chyba stejná jako dole v citaci z dmesg). Pole nešlo odpojit, že prý je používané, tak jsem restartoval.

Po restartu na mě bafá error:

Kód: [Vybrat]
root@krato-space:~# mount /dev/mapper/space /space
mount: /space: chybný typ souborového systému, chybný přepínač, chybný superblok na /dev/mapper/space, chybí kódová stránka nebo pomocný program nebo jiná chyba.

Kód: [Vybrat]
root@krato-space:~# mount /dev/mapper/space /space -o ro,nodatacow,nodatasum,rescan_uuid_tree,usebackuproot,nologreplay
mount: /space: chybný typ souborového systému, chybný přepínač, chybný superblok na /dev/mapper/space, chybí kódová stránka nebo pomocný program nebo jiná chyba.

V dmesg:

Kód: [Vybrat]
[ 1417.319669] BTRFS info (device dm-5): force zstd compression, level 0
[ 1417.319672] BTRFS info (device dm-5): setting nodatacow
[ 1417.319682] BTRFS info (device dm-5): disk space caching is enabled
[ 1417.319683] BTRFS info (device dm-5): has skinny extents
[ 1526.548506] BTRFS error (device dm-5): bad tree block start 10958796935674774848 24225444036608
[ 1526.559154] BTRFS error (device dm-5): bad tree block start 5626120839175671030 24225443971072
[ 1526.559180] BTRFS error (device dm-5): failed to read block groups: -5
[ 1526.638363] BTRFS error (device dm-5): open_ctree failed

Zoufalý pokus o záchranu dat jejich vydolováním nevyšel:

Kód: [Vybrat]
root@krato-space:~# btrfs restore -smvio /dev/mapper/space /star1/restore/
Restoring /star1/restore/smartphones
Restoring /star1/restore/smartphones/App_Backup_Restore
Restoring /star1/restore/smartphones/App_Backup_Restore/personal
Restoring /star1/restore/smartphones/App_Backup_Restore/personal/Archive_2_20170802_014258.txt
ERROR: btrfs not compiled with zstd support
Error copying data for /star1/restore/smartphones/App_Backup_Restore/personal/Archive_2_20170802_014258.txt
Restoring /star1/restore/smartphones/App_Backup_Restore/personal/Archive_3_20180503_044336.txt
ERROR: btrfs not compiled with zstd support
Error copying data for /star1/restore/smartphones/App_Backup_Restore/personal/Archive_3_20180503_044336.txt
Restoring /star1/restore/smartphones/App_Backup_Restore/personal/Archive_2_20180503_044336.txt
ERROR: btrfs not compiled with zstd support
...

A oprava také ne:

Kód: [Vybrat]
root@krato-space:~# btrfs check --repair -p /dev/mapper/space
enabling repair mode
checksum verify failed on 24225443971072 found CE56CADF wanted 623CE031
checksum verify failed on 24225443971072 found CE56CADF wanted 623CE031
bytenr mismatch, want=24225443971072, have=5626120839175671030
ERROR: cannot open file system

Nemluvě o tom, že běh btrfs check se mi ani dříve nikdy nezdařil, protože vždy po pár hodinách došla fyzická RAM 8 GB a nevyšel ani jeden pokus na PC s RAM 48 GB. Swap mám také a velký, ale btrfs check ho nerad používá, ale to je teď jedno.

Nelze nějak příkazu mount vnutit aby ignoroval (přeskakoval) problém "bad tree block start"? Existuje jakékoliv řešení jak se dostat alespoň k většině těch 32 TB dat?

4
Server / Btrfs - errory při mount, btrfs rescue zero-log, ...
« kdy: 25. 07. 2018, 12:42:10 »
Zdravím,

mám VPS u jednoho hostingu, ten mi vlivem jeho chyby smazal celý 370 GB virtuální disk, obnovili mi ho z jejich zálohy, ale Btrfs na šifrovaném LVM při pokusu o mount píše chybu. Zkoušel jsem opravit, ale marně, viz níže. Nenapadne někoho něco jak to opravit?

Verze software

Kód: [Vybrat]
root@krato-space:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04 LTS
Release:        18.04
Codename:       bionic
root@krato-space:~# uname -a
Linux krato-space 4.17.8-041708-generic #201807180730 SMP Wed Jul 18 07:32:29 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@krato-space:~# btrfs --version
btrfs-progs v4.15.1

Chyba při mount

Kód: [Vybrat]
root@xubuntu:/media# mount /dev/mapper/linux-system linux-system
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.
root@xubuntu:/media# tail /var/log/syslog
Jul 24 18:56:57 xubuntu dhclient[2686]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 6 (xid=0x823cbd3d)
Jul 24 18:57:03 xubuntu dhclient[2686]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 9 (xid=0x823cbd3d)
Jul 24 18:57:24 xubuntu kernel: [ 2019.510859] BTRFS info (device dm-1): disk space caching is enabled
Jul 24 18:57:24 xubuntu kernel: [ 2019.510861] BTRFS info (device dm-1): has skinny extents
Jul 24 18:57:24 xubuntu kernel: [ 2019.515375] BTRFS error (device dm-1): parent transid verify failed on 290030944256 wanted 685941 found 686068
Jul 24 18:57:24 xubuntu kernel: [ 2019.516184] BTRFS error (device dm-1): parent transid verify failed on 290030944256 wanted 685941 found 686068
Jul 24 18:57:24 xubuntu kernel: [ 2019.516188] BTRFS warning (device dm-1): failed to read tree root
Jul 24 18:57:24 xubuntu kernel: [ 2019.576034] BTRFS error (device dm-1): open_ctree failed
Jul 24 18:57:21 xubuntu dhclient[2686]: message repeated 2 times: [ DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 9 (xid=0x823cbd3d)]
Jul 24 18:57:30 xubuntu dhclient[2686]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 12 (xid=0x823cbd3d)

Marné pokusy o opravu

Kód: [Vybrat]
root@xubuntu:/media# mount /dev/mapper/linux-system linux-system -o ro,usebackuproot
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.

Kód: [Vybrat]
root@xubuntu:/media# btrfs rescue zero-log /dev/mapper/linux-system
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: could not open ctree

Kód: [Vybrat]
root@xubuntu:/media# btrfs check /dev/mapper/linux-system
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
Ignoring transid failure
Couldn't setup extent tree
ERROR: cannot open file system

Kód: [Vybrat]
root@xubuntu:/media# mount /dev/mapper/linux-system linux-system -o ro
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.

Dodatek: Zkusil jsem i mount -o recovery, ale také bez úspěchu.

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

6
Server / ZFS pozastavuje zápis po zaplnění bufferu
« kdy: 03. 03. 2016, 16:48:41 »
Zdravím,

koupil jsem klasický 8 TB SATA disk, vytvořil mdadm RAID 1, v něm dm-crypt/LUKS, v něm ZFS pool verze 23 (kvůli kompatibilitě se ZFS-FUSE), vytvořil několik subvolume a nastavil [dedup=on,compression=gzip,checksum=on,atime=off]. Přidal jsem cache a log na SSD disku. Disk jsem téměř celý zaplnil celkem řádově miliony souborů a desítky snapshotů. Software je Linux Mint 17.1 s jádrem 3.13.0-37-generic, k ZFS přistupuji přes ubuntu-zfs (http://zfsonlinux.org/) a používám zfs-auto-snapshot.

Zlobí zápis na disk přes "ZFS on Linux" (http://zfsonlinux.org/). Při ukládání většího souboru přes rsync, cp, dd, ... se nejprve ukládá rychlostí kolem 40 MB/s cca 400 MB a pak se na několik minut ukládající proces pozastaví a takto střídavě pořád dokola. V příkazu top je vidět velká aktivita disku a procesu myslím z_wr_iss. Nepříjemné je to, že při tom pozastavení procesu jsou pozastaveny všechny procesy, které provádí zápis na pool nebo nějakou náročnější operaci s poolem. Toto pozastavení zápisů na několik minut dělá problémy např. při stahování souboru z internetu. Mám podezření na zaplnění cca 400 MB bufferu v RAM, který pak blokuje zápis na pool dokud se nevyprázdní na fyzický disk, což probíhá rychlostí kolem 1 MB/s. Lze nějak velikost tohoto bufferu snížit?

Podobně se chová i mazání snapshotů, při kterém dochází k údajné zátěži systému ("load") kolem 100 a po několika hodinách mazání přestává být systém ovladatelný na dálku a je nutný hardwarový restart. Ukládání většího souboru se pokaždé úspěšně dokončí střídáním dvou fází zmíněných výše, v dlouhodobém průměru rychlostí kolem 1 MB/s, ohledně které mám podezření na zpomalení deduplikací, což bych ještě akceptoval.

Zkusil jsem implementaci ZFS-FUSE, ale kromě toho, že postrádá některé funkce (např. mountování snapshotů), jiné zlobí (např. záhadný problém s oprávněními, kde pomohl chown na uživatele, který ale již byl nastaven), tak navíc mám špatné zkušenosti se stabilitou. Asi po hodině používání najednou adresáře s daty na ZFS začaly házet chybu myslím "Transport endpoint is not connected". Na druhou stranu data zapisoval plynule rychlostí cca 1 MB/s.

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.

Dříve jsem používal Btrfs, ale chybí mu např. in-band deduplikace a také pokus o zapnutí quota systému na plném 8 TB disku běžel několik dní s pozastavením všech zápisů na disk, následovaným vynuceným hw restartem. Naštěstí data poškozena nebyla.

Právě v tomto okamžiku čekám už 2 hodiny na smazání jednoho snapshotu, po úspěšném nebo neúspěšném dokončení budu moci zjistit k problémům výše na požádání detaily.

Doporučte prosím buď řešení zmíněného "buffer" problému s Native ZFS na Linuxu a nebo spolehlivou implementaci ZFS na kterémkoliv open-source OS a nebo jiný souborový systém s funkcemi ZFS. Potřebuji spolehlivost a co největší plynulost zápisu a čtení, není prioritou rychlost. Zkusím pozastavit vytváření snapshotů utilitou zfs-auto-snapshot, ale myslím, že už jsem to jednou marně zkusil. Navíc k pozastavení zápisů na pool dochází spíše po zaplnění cca 400 MB bufferu než periodicky např. každé 4 minuty.

Pokud máte zkušenosti s něčím zmíněným výše na několika TB disku nebo poli s miliony nebo více souborů, budu za ně rád.

Děkuji za přečtení delšího textu, nechtěl jsem vynechat nic podstatného.

7
Desktop / Vzdálená plocha fungující jako ve Windows
« kdy: 09. 04. 2015, 00:25:12 »
Ahoj,

nyní potřebuji více než kdykoliv dříve pomoci s nalezením řešení pro vzdálenou plochu fungující v podstatě shodně jako ta ve Windows, tj. dle následujícího scénáře:

  • Přijdu do práce, přihlásím se na svém PC s Linuxem, v mém případě Linux Mint 17 KDE.
  • Pracuji v nativním Linuxu.
  • Jdu na oběd, tj. uzamknu monitor (zobrazena jen výzva pro zadání hesla).
  • Na obědě si vzpomenu, že se chci připojit do relace na tom PC.
  • Vezmu mobil s Androidem, připojím se a vidím na něm přesně to, jako kdybych v práci odemkl monitor zadáním hesla. V práci ale kolegové vidí stále jen výzvu na zadání hesla (tj. nelze použít řešení, kde vidím na mobilu přesně to, co je vidět na monitoru, což mi dělá např. x11vnc nebo NX server). Toto připojení nesmí vytvořit novou relaci (dělá mi xrdp když zvolím jiné rozlišení), když už pod tím uživatelem jedna existuje.
  • Pracuji připojený z mobilu. Musím mít možnost zvolit si rozlišení (např. shodné s rozlišením mobilu). Ideálně jsou forwardnuté zvuky, vybrané adresáře, USB porty, propojená schránka apod., výhodou je efektivní protokol, jelikož na mobilu mohu mít 3G či pomalé WiFi připojení.
  • Vrátím se do práce. Zadám heslo. To mě odpojí na mobilu a já mohu pokračovat v práci dál.
  • Jdu domů, tj. uzamknu monitor.
  • Situace se opakuje, akorát doma se místo z mobilu připojím z PC. Ideálně podpora PC s Linuxem i s Windows (kdybych byl u některého ještě nezkonvertovaného kamaráda).

Velmi blízko tomuto scénáři je můj aktuální stav: Linux běží ve virtuálce VirtualBox. Virtuálka se automaticky spustí při bootu hostitelského Linuxu. Virtuálka je "headless", tj. nevidím monitor hostovaného Linuxu. Na Linux ve virtuálce se připojuji protokolem NX, který umí všechno to forwardování zvuku apod. a navíc pro přenos obrazu používá dokonce video kodek VP8, který mi docela vyhovuje. Umí také propojenou schránku a má client verze pro Linux, Windows i Android. Při nefunkčnosti NX, třeba protože jsem se ve virtuálce ještě nepřihlásil, mohu použít klasické RDP (umí VirtualBox). V práci pracuji připojený přes NX (resp. RDP) na localhost. Když jdu na oběd, tak se v NX klientu odpojím a uzamknu nativní monitor, ale virtuálka běží dál a já se mohu přes NX (či RDP) připojit z mobilu. Stejně tak pak večer z PC doma. Vadí mi na tom, že Linux, ve kterém pracuji, neběží nativně, ale běží ve virtuálce. Snižuje to mírně výkon CPU, hodně 3D výkon a třeba na programování grafických karet (OpenCL) mohu rovnou zapomenout.

Velmi děkuji za případné rady a každopádně děkuji za přečtení.

Stran: [1]