Témata

1

Software / Utilita du se chová divně nad NFS/BTRFS

« kdy: 14. 09. 2025, 12:02:56 »

Asi skrvny na slunci, nebo jako fakt nechápu co se děje. Rozbilo se mi du na straně, kde je NFS klient. Na straně serveru jsou výsledky vždy ok - tak jak je předpokládám.

Mám aktualizovaný Gentoo,

Kód: [Vybrat]

$ du --version
du (GNU coreutils) 9.7
Packaged by Gentoo (9.7 (p0))

Ve složce je 30 položek (adresářů ~ subvolumes), ale zobrazí se jenom první:

Kód: [Vybrat]

$ sudo du --si -sh *
1.7T    xxx
Tak zkusím pustit du jen na dvoje - taky zobrazuje jenom první:

Kód: [Vybrat]

$ sudo du --si -sh xxx yyy
43G     xxx

$ sudo du --si -sh yyy xxx
13G     yyy

Přidám podsložku v prvním argumentu - druhý se zobrazuje nulový:

Kód: [Vybrat]

$ sudo du --si -sh yyy/zzz xxx
13G     yyy/zzz
0       xxx

Přidám dvě podsložky v prvním argumentu - druhý se zobrazuje správně:

Kód: [Vybrat]

$ sudo du --si -sh yyy/zzz/www xxx
78M     yyy/zzz/www
43G     xxx

Ty složky jsou každá jako individuální btrfs subvolume, ale nevolám du s --one-file-system, že by měl vůbec řešit zda jede v jenom nebo ne. Volání s --apparent-size se chová sejně. Strace nezobrazuje chybu.. načte adresář a pak se to rozhodne traversing ukončit ať už s výpisem nebo bez.

Je možné, že se něco ztratilo v překladu při té kombinaci NFS + BTRFS subvolumes?

Lze tohle nějak ladit a odkrokovat např. v kombinaci VScode + gdb, abych viděl co si to tedy myslí, že to nechce chodit?

2

Software / Sdílená grafika s video výstupy pod VM

« kdy: 05. 09. 2025, 22:23:30 »

Ahoj, mám tu silné cpu a silnou GPU (nvidia rtx aXXXX rada, tj. nastupce quadro) - a chci udělat multi-seat setup.

Dá se nasdílet grafika vícero virtuálům a zachovat jeden či dva video výstupy pro každou VM ?
(GPU má 4x DP, mám buď 4 monitory nebo 2+1 monitor co vyžaduje dva DP kabely)

Našel jsem zatím jen od NVidie vGPU - a to je o sdílení compute/memory resources.. neřeší to video výstup (CRTC?).

Jak by jste tento setup řešili po sw stránce, když nechci gpu passthrough a přiřadit celou kartu do jednoho VM ?
(a více karet pak dost popírá myšlenku konsolidace ... taky máme přece NAS, aby šlo sdílet storage.. cpu se sdílí.. ale co GPU ?)

Neříkejte že to GPU budu moci využít jen jako výpočetní, nebo jenom v hypervisoru (nebo jedné VM), která bude ostatní virtuálky s emulovanou grafikou zobrazovat a la vnc/spice.

Po dvou třech dekádách vývoje virtualizací bych čekal že řešení bude existovat.

3

Software / Nekorektní chování BTRFS

« kdy: 25. 07. 2025, 15:00:52 »

Ahoj, mám pole z 8x 14TB disků v BTRFS RAID-6 režimu, tj. 84TB využitelného místa.
Ve stavu kdy bylo volné místo hlášeno jako 131 GB se to remountlo do RO - kvůli "chybě" - prý došlo místo.

Pak jsem chvíli zápasil to rychle zprovoznit (různé logování mám přesměrováno taky na tenhle storage a hlásilo to co minutu nemožnost zápisu) ... remount,rw nešlo - prý je FS v nekonzistentním stavu či má chybu.. takže jsem to musel odmountovat, odmountovat všechny bind mounty a vypnout NFS. A pak remountnout s pár volbama navíc, aby to bylo zas v RW a mohl jsem tam smazat pár stovek GB a vyřešit tím nouzi.

dmesg panic:

Kód: [Vybrat]

[24691097.702274] ------------[ cut here ]------------
[24691097.702280] BTRFS: Transaction aborted (error -28)
[24691097.702326] WARNING: CPU: 16 PID: 8114 at fs/btrfs/free-space-tree.c:865 remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.702478] Modules linked in: exfat ntfs3 rpcsec_gss_krb5 nfsv4 btrfs dm_crypt nfsd auth_rpcgss nfs_acl nfs lockd grace netfs sunrpc ipmi_ssif skx_edac skx_edac_common x86_pkg_temp_thermal coretemp kvm_intel mlx4_ib i2c_i801 ib_uverbs i2c_smbus input_leds mei_me mei acpi_power_meter ipmi_si acpi_ipmi ipmi_devintf ipmi_msghandler efivarfs ixgbe xfrm_algo megaraid_sas
[24691097.702539] CPU: 16 UID: 0 PID: 8114 Comm: btrfs-transacti Not tainted 6.11.0-gentoo-x86_64 #5
[24691097.702547] Hardware name: Supermicro Super Server/X11SPL-F, BIOS 3.9 03/15/2023
[24691097.702550] RIP: 0010:remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.702675] Code: ff ff ff e8 c3 2f f4 ff eb 8e 4c 89 ef bd fe ff ff ff e8 b4 2f f4 ff e9 7c ff ff ff 89 ee 48 c7 c7 d8 aa 92 c0 e8 91 6a 92 f0 <0f> 0b eb c6 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
[24691097.702681] RSP: 0018:ffffb89342767c80 EFLAGS: 00010282
[24691097.702686] RAX: 0000000000000000 RBX: ffff98da12df98f0 RCX: 0000000000000000
[24691097.702691] RDX: 0000000000000002 RSI: 0000000000000027 RDI: 00000000ffffffff
[24691097.702695] RBP: 00000000ffffffe4 R08: 00000001017914bb R09: 0000000000000001
[24691097.702698] R10: 00000001017914bb R11: ffff98f8fe800000 R12: 0000000000004000
[24691097.702702] R13: ffff98ea8a3f0b60 R14: ffff98da3f1bd400 R15: ffff98da3f1bd5e0
[24691097.702705] FS:  0000000000000000(0000) GS:ffff98f8ffe00000(0000) knlGS:0000000000000000
[24691097.702710] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[24691097.702714] CR2: 00007ff570b240d0 CR3: 0000000c3e248001 CR4: 00000000007706f0
[24691097.702717] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[24691097.702720] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[24691097.702723] PKRU: 55555554
[24691097.702726] Call Trace:
[24691097.702731]  <TASK>
[24691097.702736]  ? __warn+0x7c/0x120
[24691097.702749]  ? remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.702872]  ? report_bug+0x18d/0x1c0
[24691097.702881]  ? handle_bug+0x3a/0x70
[24691097.702889]  ? exc_invalid_op+0x13/0x60
[24691097.702896]  ? asm_exc_invalid_op+0x16/0x20
[24691097.702910]  ? remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.703034]  alloc_reserved_extent+0x1f/0xd0 [btrfs]
[24691097.703140]  __btrfs_run_delayed_refs+0xb04/0x1070 [btrfs]
[24691097.703252]  btrfs_run_delayed_refs+0x5d/0x110 [btrfs]
[24691097.703359]  btrfs_commit_transaction+0x5c7/0xe20 [btrfs]
[24691097.703489]  ? start_transaction+0xc0/0x840 [btrfs]
[24691097.703610]  transaction_kthread+0x155/0x1c0 [btrfs]
[24691097.703728]  ? __pfx_transaction_kthread+0x10/0x10 [btrfs]
[24691097.703844]  kthread+0xda/0x110
[24691097.703853]  ? __pfx_kthread+0x10/0x10
[24691097.703860]  ret_from_fork+0x2d/0x50
[24691097.703866]  ? __pfx_kthread+0x10/0x10
[24691097.703873]  ret_from_fork_asm+0x1a/0x30
[24691097.703883]  </TASK>
[24691097.703885] ---[ end trace 0000000000000000 ]---

a samotný BTRFS v dmesg dopsal tohle:

Kód: [Vybrat]

[24691097.703890] BTRFS info (device dm-1 state A): dumping space info:
[24691097.703896] BTRFS info (device dm-1 state A): space_info DATA has 131499511808 free, is full
[24691097.703901] BTRFS info (device dm-1 state A): space_info total=83864976359424, used=83733476028416, pinned=28672, reserved=0, may_use=4096, readonly=786432 zone_unusable=0
[24691097.703909] BTRFS info (device dm-1 state A): space_info METADATA has 0 free, is full
[24691097.703913] BTRFS info (device dm-1 state A): space_info total=138110042112, used=136951889920, pinned=1140146176, reserved=17219584, may_use=0, readonly=786432 zone_unusable=0
[24691097.703920] BTRFS info (device dm-1 state A): space_info SYSTEM has 8159232 free, is not full
[24691097.703924] BTRFS info (device dm-1 state A): space_info total=12582912, used=4423680, pinned=0, reserved=0, may_use=0, readonly=0 zone_unusable=0
[24691097.703930] BTRFS info (device dm-1 state A): global_block_rsv: size 536870912 reserved 0
[24691097.703934] BTRFS info (device dm-1 state A): trans_block_rsv: size 0 reserved 0
[24691097.703937] BTRFS info (device dm-1 state A): chunk_block_rsv: size 0 reserved 0
[24691097.703940] BTRFS info (device dm-1 state A): delayed_block_rsv: size 0 reserved 0
[24691097.703944] BTRFS info (device dm-1 state A): delayed_refs_rsv: size 988413952 reserved 0
[24691097.703948] BTRFS: error (device dm-1 state A) in remove_from_free_space_tree:865: errno=-28 No space left
[24691097.703954] BTRFS info (device dm-1 state EA): forced readonly
[24691097.703962] BTRFS error (device dm-1 state EA): failed to run delayed ref for logical 6309443567616 num_bytes 16384 type 176 action 1 ref_mod 1: -28
[24691097.703971] BTRFS: error (device dm-1 state EA) in btrfs_run_delayed_refs:2199: errno=-28 No space left
[24691097.703977] BTRFS warning (device dm-1 state EA): Skipping commit of aborted transaction.
[24691097.703981] BTRFS: error (device dm-1 state EA) in cleanup_transaction:2018: errno=-28 No space left

mount -o remount,rw ... nedopadl. Takže jsem musel zastavit vše co tam šahalo a dát umount:

Kód: [Vybrat]

[24691687.760428] BTRFS error (device dm-1 state EMA): remounting read-write after error is not allowed
[24692290.779067] BTRFS info (device dm-1 state EA): last unmount of filesystem 88be0937-6cfe-4208-b838-058a1c989367


Kód: [Vybrat]

[24692304.008806] BTRFS info (device dm-1): first mount of filesystem 88be0937-6cfe-4208-b838-058a1c989367
[24692304.008843] BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm
[24692304.008851] BTRFS info (device dm-1): using free-space-tree
[24692393.382389] BTRFS info (device dm-1): rebuilding free space tree

Je to nějaká chyba v BTRFS (kernel zde je 6.11.0) - nebo proč si to nedokázalo zvětšit metadata region?

Dá se tomu při mkfs říct, že chci více metadat ? Ono to btrfs je celkem divný v tom, že neoznamuje počet a využití inodes (tak jsem předpokládal, že si to dokáže řešit sám dynamicky).

Ale stejně.. wtf je "space_info DATA has 131499511808 free, is full" ?

Jsem nečekal, že produkční FS v mainline bude házet kernel panic, jen proto, že jsem disk zaplnil způsobem, jaký asi autoři nečekali :D

A teď jak jsem chtěl napsat kolik je tam souborů - skrze "find . | grep -n .", tak stovky GB volného místa zmizelo - aplikace tam zapisující hlásí no free space a zápis nejde - skrze "watch -n 1 df -H" vidím různě problikávat dvě varianty stavu:

Kód: [Vybrat]

113T   84T     0 100% /mnt/****
↕
113T   84T  909G 100% /mnt/****
WTF, co se to děje na tom FS ?

Ctrl+Z pro ten find, smažu/přesunu film s 10GB .. objeví se 917G volného místa, fg .. find pokračuje a za vteřinu volné místo 0. To fakt nechápu co to jako dělá. A proč RO úloha jako find - procházení adresářů, má vůbec vliv na volné místo.

Když sleduji odsun souborů - tak místo v "df" narůstá po cca 10GB jak je velikost těch souborů, ale tady se nic nemění - ani během odsunu, ani během běhu find příkazu. Přitom po odsunu volné místo je a zápis logů probíhá.. ale jakmile pustím find.. tak df hlásí nulu a zápisy nejdou. Neskutečný bordel.

btrfs fi df /mnt/****

Kód: [Vybrat]

Data, RAID6: total=76.27TiB, used=75.42TiB
System, RAID6: total=12.00MiB, used=4.22MiB
Metadata, RAID6: total=134.62GiB, used=134.11GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

(podle starého uloženého indexu by tam mělo být 43M souborů)

Tak ještě koukám na: btrfs fil usage /mnt/****

Kód: [Vybrat]

Overall:
    Device size:                 101.87TiB
    Device allocated:            101.87TiB
    Device unallocated:            8.00MiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        100.70TiB
    Free (estimated):            892.56GiB      (min: 892.56GiB)
    Free (statfs, df):               0.00B
    Data ratio:                       1.33
    Metadata ratio:                   1.33
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,RAID6: Size:76.27TiB, Used:75.40TiB (98.86%)
~
Metadata,RAID6: Size:134.62GiB, Used:134.12GiB (99.63%)
~
System,RAID6: Size:12.00MiB, Used:4.22MiB (35.16%)
~

A přijde mi, že mu schází místo v metadatech, a nemůže se alokovat žádnej další 1GB chunk pro ně.. protože tam je vše zabrané datovýmy chunky... které se z nějakého důvodu neuvolňují.

Takže zkusím: btrfs balance start -v -dusage=10 /mnt/****

Kód: [Vybrat]

Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x2): balancing, usage=10
ERROR: error during balancing '/mnt/****/': No space left on device
There may be more info in syslog - try dmesg | tail

Tak to je další WTF.. nemůže to uvolnit místo, protože "není" volné místo :D .... Hlava XXII.

Mažu další soubory a "uvolňuji" desítky GB, find je pořád pozastaven.
Rebalance (s dusage=10) znova.. už to jede a dmesg se plní realokacema.. a volné chunky rostou. Konečně!

Tak jsem se posunul z

Kód: [Vybrat]

Overall:
    Device size:                 101.87TiB
    Device allocated:            101.87TiB
    Device unallocated:            8.00MiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        100.68TiB
    Free (estimated):            909.33GiB      (min: 909.33GiB)
    Free (statfs, df):           909.33GiB
    Data ratio:                       1.33
    Metadata ratio:                   1.33
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

na

Kód: [Vybrat]

Overall:
    Device size:                 101.87TiB
    Device allocated:            101.12TiB
    Device unallocated:          767.06GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        100.68TiB
    Free (estimated):            909.38GiB      (min: 909.38GiB)
    Free (statfs, df):           909.38GiB
    Data ratio:                       1.33
    Metadata ratio:                   1.33
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

a find nechal dojet - a naplnil se předpoklad, že procházení/čtení konzumuje místo!!, viz stav před/po:

Kód: [Vybrat]

Metadata,RAID6: Size:134.62GiB, Used:133.98GiB (99.52%)
↓
Metadata,RAID6: Size:142.88GiB, Used:142.19GiB (99.52%)

To je peklo s tím COW, že to potřebuje takovy "vacuum" jak pg ... a nikdo se o tom pořádně nezmiňuje ať si ten rebalance přidáš do cronu !

Ale asi pořád lepší to mít pod kontrolou, než aby uklízečka jela v kthreadu a řádila kdy to člověk nečeká a např. manipuluje s disky.

Na druhou stranu.. v případě, že alokace došla na konec, tak by měl proběhnout automatický rebalance pro získání alepoň jednoho volného chunku.. a to se neděje. Raději bych těch 10-20 sec IO latence přežil.. než -ENOSP, nebo nedejbože broken flag + RO.

Anketa.. kdo máte BTRFS a víte o nutnosti rebalance (defakto defragmentace a vacuuming) - a kdo ho v cronu i máte - nebo jste ještě nedošli na konec volného místa ?

PS. Snapshoty v této sérii problémů nehrají roli (mazaná data nejsou uzamčená snapshotem)

PS2. Je tam 42.288.071 souborů.

4

Server / Jaký DNS resolver pro LAN a VPN?

« kdy: 30. 06. 2025, 13:23:08 »

Ahoj - mám dotaz - co za SW nasadit pro interní DNS systém, který bude resolvovat privátní adresy v lokální síti, nebo pro připojené klienty skrze VPN.

Buď jako overlay (prioritu mají pak lokální záznamy), nebo jako dedikovaný pro konkrétní subdomény.

A co není obslouženo/definováno.. tak se doptá zvenku. Plus bych čekal cachování dle TTL a nějaké to logování / statistiky.

5

Windows a jiné systémy / Mount v macOS rozbije Finder

« kdy: 02. 05. 2025, 10:29:02 »

Ahoj, řešíme jeden problém - při namountování virtuálního filesystému (přes FSKit) v terminálu je normálně dostupný obsah, ale ve Finderu je daný mountpoint neviditelný - prostě složka zmizne ze seznamu souborů. Objeví se ale znova po umountu.

Mountujeme to do obyčejné pod-složky v jiné složce, protože do /Volumes to zatím netuším jak dostat (to je read-only a mountpoint tam vytváří bůhví co).

Nějaký nápad proč se tak děje a kde hledat potíže či jak debuggovat co si myslí Finder?

(jiné aplikace při ručním nabrowsování do dané složky data vidí správně)

A pak - jaká magie řeší viditelnost mountů ve /Volumes ?

6

/dev/null / Ministerstvo nerozumi jak internet funguje

« kdy: 13. 03. 2025, 11:41:56 »

Jsem si precetl clanek:

https://www.idnes.cz/zpravy/domaci/ministerstvo-vnitra-prumyslu-obchodu-kontrola-internetu.A250313_085104_domaci_ikro

A uvadi se tam:

V současnosti poskytovatelé už shromažďují informace o IP adresách uživatelů, tedy odkud se k internetu připojují.
Nezaznamenávají ale, jaké konkrétní stránky navštěvují.
Navrhovaná změna by zavedla sběr tzv. cílových IP adres, což by umožnilo zjistit, jaké weby uživatelé navštívili, včetně času návštěvy a délky strávené na stránce.

V pripade otevreneho DNS, se da zjistit priblizna domena, o kterou mel uzivatel zajem, ale pak uz je vse prece nejlepe HTTPS - a samotne requesty na URL uz nejsou viditelne pro nekoho po ceste. A delku stravene na strance je totalne nemozne zjistit, pokud stranka nema nejaky AJAX co by periodicky bonzoval zda ma uzivatel neco otevreneho.

Totalne nechapu jak si nekdo z vedoucich pozic muze vymyslet takovy pozadavek, ktery nelze splnit.

To je jako kdyby rekli zemedelcum, ze maji kvoty na dodani plodin, rozprostrene zcela identicky v celem roku
Nebo elekrarnam, at nasadi perpetum mobile - prece existuje spousta odborniku skrze volnou energii


Opravdu bych chtel osobne potkat cloveka, co vyplodil tenhle pozadavek. Muzeme ho identifikovat?

7

Vývoj / Pomoc s ARM periferií

« kdy: 06. 01. 2025, 18:09:27 »

Myslím, že se tady najde i několik odborníků - řeším oživení a "BSP" pro projekt odvozený od Arduino DUE desky.

TLDR: Nefunguje mi zápis do PIO výstupů paralelně, jen skrze set/clear registry. Hodiny pro perfierii jsem povolil.


Relevantní kusy kódu:

Kód: [Vybrat]

#define config_pio_out( port, bits ) \
    port->PIO_PER  = bits; \
    port->PIO_OER  = bits; \
    port->PIO_PUDR = bits;

#define update_pio( port, bits, enable ) \
    if (enable) { \
        port->PIO_SODR = bits; \
    } else { \
        port->PIO_CODR = bits; \
    }

/*
    OCRX[8:1] = PC[27:20]
    OCTX[8:1] = PD[7:0]
*/

#define OPTO_TX_DEFAULT         0x00

#define OPTO_TX_OFFS    0
#define OPTO_TX_MASK    ( PIO_PD7 \
                        | PIO_PD6 \
                        | PIO_PD5 \
                        | PIO_PD4 \
                        | PIO_PD3 \
                        | PIO_PD2 \
                        | PIO_PD1 \
                        | PIO_PD0 )

void config_digital_out(void) {
    // for ODSR to work?
    PMC->PMC_PCER0 = 1 << ID_PIOD;
    // classic
    config_pio_out( PIOD, OPTO_TX_MASK );
    update_digital_out( OPTO_TX_DEFAULT );
}

void update_digital_out( unsigned bits ) {
    #if 1
        PIOD->PIO_ODSR = ( PIOD->PIO_ODSR & ~(OPTO_TX_MASK) )
                       | ( (bits<<OPTO_TX_OFFS) & (OPTO_TX_MASK) );
    #else
        update_pio( PIOD, PIO_PD7, bits & BIT(7) );
        update_pio( PIOD, PIO_PD6, bits & BIT(6) );
        update_pio( PIOD, PIO_PD5, bits & BIT(5) );
        update_pio( PIOD, PIO_PD4, bits & BIT(4) );
        update_pio( PIOD, PIO_PD3, bits & BIT(3) );
        update_pio( PIOD, PIO_PD2, bits & BIT(2) );
        update_pio( PIOD, PIO_PD1, bits & BIT(1) );
        update_pio( PIOD, PIO_PD0, bits & BIT(0) );
    #endif
}
a

Kód: [Vybrat]

// ./system/CMSIS/Device/ATMEL/sam.h
#include <sam.h>
#include <libsam/include/pmc.h>

:

int main( int argc, char *argv[] ) {

    /* Initilize the SAM3 system */
    SystemInit();

    config_digital_out();

    while(1) {

        static unsigned n = 0;
        n = ( n + 1 ) & 0xFF;

        update_digital_out( n );

    }

    return 0;
}

Po zmene #if 1 na #if 0 v update_digital_out(), se generuje pattern s frekvenci ktera je polovina/dvojnasobek kazdym dalsim bitem, pri pouziti ODSR se ale nic nedeje, vsechny piny jsou v nule. Mam tam nejaky preklep nekde? Nebo to co chci nejde udelat? Nebo jsem jen na neco dalsiho zapomnel? Nebo snad nejaka errata?

Kod pro SAM3X8E cpu jsem vzal z Arduino gitu: https://github.com/arduino/ArduinoCore-sam ale builduji si aplikaci uz mimo IDE, linkuji to skrze linker script a .a pro tu systemovou knihovnu z Arduina.

Ostatni veci funguji (jako SystemInit a pak mam i SysTick_Config a na nej navazany delay_ms, jen ten IO port ne a nevim kde je chyba - s temito mcu nedelam.

Arduino samotne nema IO primitiva na ovladani portu timto stylem, a hodiny pro periferii povoluje jen kdyz na portu je alespon jeden pin jako vstup (asi kvuli glitch filtru a prerusenim).

8

Software / Rsync se nezastaví na chybě

« kdy: 04. 01. 2025, 13:38:38 »

Ahoj, kopiruji data z USB SSD ktere neni v nejlepsim stavu, a po ruznych pokusech jsem zjistil ze kdyz se kopiruji pomalu, tak to vykazuje mene chyb. Tu pomalost jsem dostahl pres rsync --bwlimit option, ale pak kdyz dojde k chybe, tak to rsync vesele ignoruje a kopiruje same nuly.

Jak rict rsyncu, aby pri "read error" skoncil ? (napr. mc ve stejnem pripade o chybe vi a zastavi se)

Cely prikaz je:

Kód: [Vybrat]

rsync -ai --progress --partial --append --bwlimit=1000 /mnt/usb/neco/ /mnt/sata/neco

A chyba disku takhle:

Kód: [Vybrat]

Jan 04 05:26:51 [kernel] sd 10:0:0:0: Device offlined - not ready after error recovery
Jan 04 05:26:51 [kernel] sd 10:0:0:0: rejecting I/O to offline device

Jde o exfat (s kernel driverem).

Ze tam je chyba nejakym zpusobem musi rsync vedet, protoze od tech cca 5:26 jsou vsechny poskozene soubory s aktualnim create/modify date, zatimco pred tim selhanim blokoveho zarizeni rsync prenastavil timestampy podle zdroje. Takze jsem nastesti mohl identifikovat a odstranit ty falesne data.


Celej log:

Kód: [Vybrat]

Jan 04 04:25:01 [kernel] usb 2-7: reset SuperSpeed Plus Gen 2x1 USB device number 23 using xhci_hcd
Jan 04 04:25:01 [kernel] sd 10:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s
Jan 04 04:25:01 [kernel] sd 10:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 0a 0f a4 00 00 00 01 00 00 00
Jan 04 04:25:01 [kernel] I/O error, dev sdd, sector 168797184 op 0x0:(READ) flags 0x80700 phys_seg 16 prio class 0
Jan 04 05:01:01 [CROND] (root) CMD (run-parts /etc/cron.hourly)
Jan 04 05:01:01 [CROND] (root) CMDEND (run-parts /etc/cron.hourly)
Jan 04 05:25:23 [kernel] usb 2-7: reset SuperSpeed Plus Gen 2x1 USB device number 23 using xhci_hcd
Jan 04 05:25:23 [kernel] sd 10:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s
Jan 04 05:25:23 [kernel] sd 10:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 0b 3a a3 00 00 00 02 00 00 00
Jan 04 05:25:23 [kernel] I/O error, dev sdd, sector 188392192 op 0x0:(READ) flags 0x80700 phys_seg 9 prio class 0
Jan 04 05:25:53 [kernel] usb 2-7: reset SuperSpeed Plus Gen 2x1 USB device number 23 using xhci_hcd
                - Last output repeated 4 times -
Jan 04 05:26:51 [kernel] sd 10:0:0:0: Device offlined - not ready after error recovery
Jan 04 05:26:51 [kernel] sd 10:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=88s
Jan 04 05:26:51 [kernel] sd 10:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 0b 3a a3 00 00 00 00 08 00 00
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392192 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:51 [kernel] sd 10:0:0:0: rejecting I/O to offline device
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392704 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392192 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:51 [kernel] I/O error, dev sdd, sector 188392448 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188392960 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188392960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393472 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393472 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393984 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:52 [kernel] I/O error, dev sdd, sector 188393984 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] blk_print_req_error: 32 callbacks suppressed
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188402688 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188402688 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403200 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403200 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403712 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188403712 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188404224 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:57 [kernel] I/O error, dev sdd, sector 188404224 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:26:58 [kernel] I/O error, dev sdd, sector 188404736 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jan 04 05:26:58 [kernel] I/O error, dev sdd, sector 188404736 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 04 05:27:02 [kernel] blk_print_req_error: 30 callbacks suppressed


9

Sítě / Jumbo frames v kombinaci s VLAN

« kdy: 15. 11. 2024, 17:51:42 »

Snažím se (zatím v linuxu) nastavit sdílenou síťovku skrze VLAN do dvou sítí na různé MTU a nejde to.

Představa cílového stavu je:
eth0 s MTU 1500, subnet hlavni
eth0.10 s MTU 9000, subnet jiny

Při nastavení MTU pro rozhraní s VLAN (eth0.10) se vrací s jakoukoliv hodnotou:

Kód: [Vybrat]

SIOCSIFMTU: Numerical result out of range
Při nastavení MTU pro netagovanou síť (eth0) se tato hodnota projevuje o obou rozhraní (eth0, eth0.10)

Existuje nějaké řešení ?

Lze omezit na linuxu a macu MTU na vrstvě IP podsítě ?

Situace je: klasická domácí síť s hromadou různorodých zařízení má několik zařízení, mezi kterými chci provozovat ty jumbo frames (řekněme několik pracovních stanice a NAS), bez toho, abych musel tahat duplicitní kabeláž. Představa byla nasadit tagovanou VLAN, kde může tento jumbo provoz probíhat. A ejhle.. nejde to. WTF.

10

Server / QEMU nad LVM se zasekává

« kdy: 03. 10. 2024, 18:49:04 »

Ahoj, posledni dobou se me deje podivna vec - QEMU proces se zasekne v neprerusitelnem sleepu (top: D state).

Konfigurace stacku je tahle:

- gentoo linux 6.11.0
- md raid1 mirror (hdd+ssd)
- lvm (pv/vg/lv)
- losetup ( posun o 1 sektor )
- qemu (9.0.2)
- winxp

Kdyz se to zasekne, tak nefunguje ani RDP z guestu (winxp), a celkove Qemu zhebne (nefunguje ani remote spice klient - a ani pripojeni na lokalni monitoring socket).

A co vic, nefunguje ani lvs prikaz na vypsani logical volumes. Proste taky D state a zasekne se.

strace lvs - me rikal posledne, ze to pouziva async io.. tak jsem podezrival tohle - pridal jsem do qemu option na disk ve tvaru ,aio=threads, ale neni s tim rozdil. Po tydnu se to ted seklo zas.

Stav je to docela neprijemny, protoze se host os neda vypnout ani restartnout - musim shodit ostatni VM, vsechny sluzby a pak to navrdo resnout, doufajic, ze systemovy oddil prezije (zatim nizsi jednotky tvrdych resetu to dalo... ext4 nad lvm).

Mam podezreni ze se sekne nejake uzamykani v jadre - ale netusim kde se divat.

Na starem jadru co tam bylo predtim to nedelalo zadny problem, ale to tam vracet nechci (6.6.52), plus byla nejaka podstatna zmena konfigurace, abych novym jadrem pokryl a sjednotil vicero stroju.

Jak by jste ladili takovou vec, co se objevi jednou za tyden? (tedy, pred tydnem jsem to potkal asi 3x v rade prvni den.. pak vznikl dodatek qemu konfigurace s aio=threads)

v lsof nejak nepoznam, na ktery fd to delalo jakou operaci? nebo jinde v sysfs? Neco jako show in-flight syscalls ?

Je fakt blby ze neni nejaky unlocker, na tyhle kernel-side locknute IO.
Klidne za cenu ze ta aplikace dostane error, spatna data nebo bude ukoncena v momente navratu syscallu.

EDIT:
pridal jsem sysrq podporu do jadra, az to padne priste at muzu udelat ten w command:
https://www.suse.com/support/kb/doc/?id=000016919

11

Sítě / Získání aktuálního firmware Cisco

« kdy: 19. 08. 2024, 18:37:24 »

Tak jsem vybalil nepouzitej switch z krabice - sehnal seriovej kablik, nastavil user/pass, IP adresu a jdu kontroloval verzi..

je tam NX-OS 10.1(1), tj. s release date 2021-02-15

Tak lezu na web ze si stahnu aktualizaci - a ejhle.. chce to nejaky service contract. Jako WTF.

To fakt nestahnu aktualni FW bez nejakeho dalsiho vypalneho? A navic nemam absolutne sanci zjistit kolik to vypalne realne bude, protoze si to vycuca nejaky nagelovanej sales z prstu?

Tahle situace pripomina ono slavne BMW za par mega, kde je vyhrivani sedadel jako subscription


Nema nemaky statni urad tohle v kompetenci - ze proste stary deravy fw se MUSI nechat aktualizovat zdarma, jinak jim napari pokuty nebo zakaz cinnosti?

12

Hardware / Prodloužení podpory Dell

« kdy: 06. 02. 2024, 01:54:43 »

Ahoj, mate nekdo zkusenosti se zmenou majitele (8K monitor puvodem z Rakouska) a naslednou reklamaci?

Tedy jeste mezitim budu muset prodlouzit nejakou formu podpory.. tak jsem zvedav co to bude stat.

A kdyz uz jsme u toho, tak dva workstationy (CZ) bych prodlouzil (ty jeste maj aktivni zaruku).. jestli se to jako oplati.

13

Sítě / DNS resolver přidává sám doménu

« kdy: 26. 01. 2024, 15:42:08 »

Ahoj, z nejakeho duvodu se mi sit zacala chovat jinak.

V /etc/resolv.conf mam jediny radek: nameserver 8.8.8.8

ping neexistujici.domena ale pinga na moji verejnou IP !

tcpdump -pni lan port 53 odhalil, ze po neuspesnem DNS dotazu na neexistujici.domena, se provede resolving jmena ve formatu: neexistujici.domena.PRG.MOJEDOMENA.COM, pricemz muj stroj ma hostname neco.prg.mojedomena.com. Takze vitr vane todtud..

Co me vrta hlavou - proc se tohle deje, kdyz v resolv.conf nemam uvedenej zadnej radek "search DOMENA" ?

Mam za to, ze se to bezne nedelo.. zmenila se najaka politika v resolvingu, nebo je to nekde nastavitelny??

Neskutecne me to otravuje, jelikoz mam v DNS wildcard na te sve domene.. takze nikdy nedostanu neexistujici domenu v prohlizeci, ale snazi se to cokoliv dotazovat po http na mem serveru :(

Tak normalne updatuji Gentoo, a posledni sitovejsi zasah byla instalace netatalk - share serveru na AFP (pac ty hnile jabka se nechtej pripojovat na SMB).

14

Sítě / VPN - detekce zda jsem doma nebo ne

« kdy: 02. 01. 2024, 10:45:11 »

Ahoj, podle čeho by bylo vhodné automaticky detekovat, zda jsem doma - v domácí síti, nebo zda jsem mimo - ve světě, a má se nahodit VPN pro přístup do domácí sítě ?

Napadá mě MAC adresa dhcp serveru, parsnutá někde z DHCP logu.

15

Odkladiště / YouTube - fejkuje nedostupnost

« kdy: 03. 12. 2023, 12:30:07 »

Tak koukam ze YT zavedl jeste prasarnejsi prasarnu

FF, anonymni okno: vse ok

FF, normalni okno s uBlock Origin:

Network Protocol Error

An error occurred during a connection to www.youtube.com.

The page you are trying to view cannot be shown because an error in the network protocol was detected.

    Please contact the website owners to inform them of this problem.