Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem Ako opravit pristup k iscsi targetu (linux)

Dnes som mal paradny den.
U zakaznika audit, rano o 4:30 sa dodrbe spojenie Samby s LUNom cez iscsi, ide do read modu only a ked ho umountnem uz sa neda namountovat.
Zaloha sa recoverovala skoro 2h a ja som mal skoro hodinovu vypoved.
Zaujimave boli hlasky linuxu pri pokuse pripojit znovu nasko.

lsblk |grep sdb
sdb 8:16 0 2.3T 0 disk
└─sdb1 8:17 0 2T 0 part

alebo

mount /dev/sdb1 /mnt/qnap
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so

Particia vyzera byt ok, ale s chybami.

file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=d6017602-ec61-42f0-a60a-09eebb0a21a3 (errors) (extents) (large files) (huge files

Opravit file system cez fsck sa neda, pretoze po case nevie citat bloky.
A teraz pointa.
Napojil som sa z domu cez VPNku. nahodil si iscsi spojenie a disk normalne (ehm cez ext2 volume manager) pripojil a vsetko z neho precital!
Na linuxe som skusal vsetko, testdisk, fsck...vlastne uz ani neviem co vsetko, ale ani po 8h prace nie som schopny namountovat to debilne LUNko z linuxov, pricom ako som pisal z winov sa tam dostanem

Viem, ze toto je uz vyssi divci, ale snad sem chodi nejaky vacsi odbornik ako ja, ktory by ma pripadne vedel nakopnut.
Samozrejme mozem cely LUN nanovo zformatovat a data tam preniest zo zalohy, ale zaujima ma, ci sa z toho da nejako elegantne vykorculovat.

Předmět Autor Datum
IMHO je něco podělaného v superbloku. Neprděl bych se s tím, disk přeformátoval a obnovil ze záloh a…
Rce 30.11.2021 00:26
Rce
Testdisk som pouzil, bohuzial particiu som opravoval z prostredia windows, pretoze Testdisk zlyhal (…
fleg 30.11.2021 07:29
fleg
To vypadá, že je na tom disku asi nějak částečně chcíplá elektronika, možná poškozené paměti s infor…
Rce 30.11.2021 22:35
Rce
Ten LUN blok je tvoreny na raid5 poli zlozeneho zo 16 SSD + 2xnvme ako cache, ale tie som predbezne… nový
fleg 01.12.2021 07:12
fleg
u ich enterprise rady naozaj nie je mozne pristupovat k LUN/iscsi datam Užasné. A to se předem nikd… poslední
Rce 02.12.2021 22:12
Rce

IMHO je něco podělaného v superbloku. Neprděl bych se s tím, disk přeformátoval a obnovil ze záloh a jestli bude fungovat, neřešil bych to dál.
Ale jsem také člověk hloubavá a zajímalo by mne, kde byla závada. Ještě můžeš zkusit GParted a obnovu oddílu funkčí "zachránit data". Také se mi odvděčuje program TestDisk. Ten dovede analyzovat co se stalo a vydoluje data i ze značně zdevastovaného filesystému. Ten program bych na to určitě pustil (pod Rootem).

btw co je v syslogu, jak ti to navrhuje použít dmesg?

Z windows tam lezeš jak, skrz ten Linux?

Testdisk som pouzil, bohuzial particiu som opravoval z prostredia windows, pretoze Testdisk zlyhal (hlasil len 128MB win particiu, netusim preco).

btw co je v syslogu, jak ti to navrhuje použít dmesg?

dmesg | tail
[73290687.288078] sdb: sdb1
[73290687.293773] sdc: sdc1
[73290714.102528] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73290769.640397] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73291681.284946] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73292314.359386] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73298212.165602] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73298224.390040] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73298424.672729] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)
[73300427.051584] EXT4-fs (sdb1): bad geometry: block count 625454347 exceeds size of device (536870911 blocks)

Takze on tvrdi, co je v poriadku, ze ten disk je vacsi ako particia (sdb1 ma 2TB, sdb ma 2.3TB). Neviem preco mu to vsak vadi.
fsck zlyha asi takto.

fsck /dev/sdb1
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
The filesystem size (according to the superblock) is 625454347 blocks
The physical size of the device is 536870911 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Error reading block 536870912 (Invalid argument) while reading inode and block bitmaps. Ignore error<y>?

A dalej uz hlasi jednotlive bloky ako vadne az kym fsck nezrusi. A je jedno, ci ich opravujem alebo nie.

Z windows tam lezeš jak, skrz ten Linux?

Nie, cez vpn sa dostanem na lanku a spustim iscsi iniciator a cez neho si mountnem disk.
Problemom je, ze ide o LUN blok, ktory samotne NASko vidi ako zvazok/disk a nema k nemu pristup, takze zo samotneho NASka neviem spravit s diskom nic a vsetko musim riesit cez iscsi klientov (velkost, file system a pod). Poslal som sice poziadavku aj na support QNAPu, ale tipujem, ze ma poslu do pecka, ze to mozne nie je. Ide totizto o enterprise model a paradoxne v lacnejsich modeloch by to slo cez pripnutie virtualneho disku (robil by sam sebe aj iscsi iniciatora aj target).

To vypadá, že je na tom disku asi nějak částečně chcíplá elektronika, možná poškozené paměti s informacemi o stopách a vadných cylindrech. Vše nasvědčuje tomu, že se nějak ten oddíl (disk) záhadně zmenšil (viz hlášení Testdisku) a v logu také to hlásí, že blok je někde mimo oddíl. Jen je mi záhadou, proč ve Widlích to funguje. Asi nejsou Windows tak důkladné na zkoumání geometrie disku. Linux jak dojede někam za údajnou kapacitu disku už nemůže nic přečíst.

Už bych udělal jediné řešení. Zkusil to přeformátovat a obnovit ze záloh. Pokud to bude blbě znova, filinknul bych diskem do popelnice za doprovodu strašlivě sprostých nadávek.

Ten LUN blok je tvoreny na raid5 poli zlozeneho zo 16 SSD + 2xnvme ako cache, ale tie som predbezne (cez smart) kontroloval a javia sa ako ok.
Inak win tiez nevidel zo zaciatku particiu, len raw disk, ale po obnove particie sa dostal k datam ako jediny...zatial;o).

Data boli zachranene, aj zaloha bola, takze uz to riesim len zo zvedavosti.
Skusim spravit este podrobnejsie kontroly ssd.

Inak uz mi odpovedala aj QNAP podpora, ze u ich enterprise rady naozaj nie je mozne pristupovat k LUN/iscsi datam, co je smutne, pretoze u ich nizsich rad to ich NASka vedia cez virtualny disk. Na masinu za 12k eur dost nemile zistenie.

Zpět do poradny Odpovědět na původní otázku Nahoru