Import ZFS pools by cache file

Min gissning är att lagringsenheterna inte var tillagda i poolen med med något beständigt namn (WWN rekommenderas väl) och att poolen inte heller exporterats för att nu importeras.
Dvs, jag förmodar att något blivit knas när det inte längre går att hitta enheten och att snabbimporten från cache har fastnat istället.

En snabb fråga:

Har du kollat kablaget?

När du får en massa errors men disken i övrigt verkar vara OK skulle det lika gärna kunna någon kabel som felar.
Har varit ute för tillfällen då man kasserat fullt fungeande HBA:er och RAID-kort när det i själva verket varit fel på antingen ström- eller data-kablar.

Att köra en(1) lagringsenhet i ZFS är att be om problem. Då är det mer driftsäkert med UFS/extX/NTFS/exFAT m.fl. Man förlorar allt om en viss plats i ZFS skadas(kommer inte ihåg vad den platsen heter men det går att googla fram den).

Går att fuska till sig om man ber ZFS att skapa två kopior(normalt är en) på samma enhet men då förlorar man hälften utav utrymmet.

ZFS är inte avsett för en(1) lagringsenhet då risken är betydligt högre att bli av med all data än när man kör UFS/extX/NTFS/exFAT m.fl.

Med det sagt, Du kör med trevlig hårdvara. Kolla om Du kommer åt IPMI gränssnittet och kör lite andra tester som bl.a. Du själv nämner. Men anslutnings/kabelfel kan heller inte uteslutas. Eftersom det är en S-ATA enhet så kan Du få ut detaljerade värde ifrån smartctl och då räcker det med den vanliga dumpen(varken kort eller lång körning krävs för att kika på värdena som disken har registrerat i S.M.A.R.T). Man kan då få tydliga ledtrådar om vart felet kan tänkas ligga.

188 och 199 ser bra ut, så det verkar tyvärr inte vara ett anslutning/kontaktfel. Dom brukar springa iväg vid dålig kontakt.

Här är lite förklaringar på engelska med möjlig felorsak(kommer från en av mina egna som hade en elektrisk kontakt med något den inte borde ha haft men lirar felfritt i en korrekt vagga:

1 Raw_Read_Error_Rate 84143528 (Vendor specific raw value.) Stores data related to the rate of hardware read errors that occurred when reading data from a disk surface. The raw value has different structure for different vendors and is often not meaningful as a decimal number.

3 Spin_Up_Time 0 Average time of spindle spin up (from zero RPM to fully operational).

4 Start_Stop_Count 349 A tally of spindle start/stop cycles. The spindle turns on, and hence the count is increased, both when the hard disk is turned on after having before been turned entirely off (disconnected from power source) and when the hard disk returns from having previously been put to sleep mode.

5 Reallocated_Sector_Ct 0 Count of reallocated sectors. When the hard drive finds a read/write/verification error, it marks that sector as 'reallocated' and transfers data to a special reserved area (spare area). This process is also known as remapping, and reallocated sectors are called 'remaps'. The raw value normally represents a count of the bad sectors that have been found and remapped. Thus, the higher the attribute value, the more sectors the drive has had to reallocate. This allows a drive with bad sectors to continue operation; however, a drive which has had any reallocations at all is significantly more likely to fail in the near future. While primarily used as a metric of the life expectancy of the drive, this number also affects performance. As the count of reallocated sectors increases, the read/write speed tends to become worse because the drive head is forced to seek to the reserved area whenever a remap is accessed. If sequential access speed is critical, the remapped sectors can be manually marked as bad blocks in the file system in order to prevent their use.

7 Seek_Error_Rate 17452705492 (Vendor specific raw value.) Rate of seek errors of the magnetic heads. If there is a partial failure in the mechanical positioning system, then seek errors will arise. Such a failure may be due to numerous factors, such as damage to a servo, or thermal widening of the hard disk. The raw value has different structure for different vendors and is often not meaningful as a decimal number.

9 Power_On_Hours 2693 Count of hours in power-on state. The raw value of this attribute shows total count of hours (or minutes, or seconds, depending on manufacturer) in power-on state.

10 Spin_Retry_Count 0 Count of retry of spin start attempts. This attribute stores a total count of the spin start attempts to reach the fully operational speed (under the condition that the first attempt was unsuccessful). An increase of this attribute value is a sign of problems in the hard disk mechanical subsystem.

12 Power_Cycle_Count 326 This attribute indicates the count of full disk power on/off cycles.

183 Runtime_Bad_Block 0 Western Digital, Samsung or Seagate attribute: Total number of data blocks with detected, uncorrectable errors encountered during normal operation.

184 End-to-End_Error 0 This attribute is a part of Hewlett-Packard's SMART IV technology, as well as part of other vendors' IO Error Detection and Correction schemas, and it contains a count of parity errors which occur in the data path to the media via the drive's cache RAM.

187 Reported_Uncorrect 0 The count of errors that could not be recovered using hardware ECC (see attribute 195).

188 Command_Timeout 12885164043 The count of aborted operations due to HDD timeout. Normally this attribute value should be equal to zero and if the value is far above zero, then most likely there will be some serious problems with power supply or an oxidized data cable.
Consider replacing this drive

189 High_Fly_Writes 0 HDD producers implement a Fly Height Monitor that attempts to provide additional protections for write operations by detecting when a recording head is flying outside its normal operating range. If an unsafe fly height condition is encountered, the write process is stopped, and the information is rewritten or reallocated to a safe region of the hard drive. This attribute indicates the count of these errors detected over the lifetime of the drive. This feature is implemented in most modern Seagate drives.

190 Airflow_Temperature_Cel 23 Value is equal to (100-temp. Celsius), allowing manufacturer to set a minimum threshold which corresponds to a maximum temperature.

191 G-Sense_Error_Rate 0 The count of errors resulting from externally induced shock & vibration.

192 Power-Off_Retract_Count 221 Count of times the heads are loaded off the media. Heads can be unloaded without actually powering off.

193 Load_Cycle_Count 639 Count of load/unload cycles into head landing zone position.

194 Temperature_Celsius 23 Current internal temperature.

195 Hardware_ECC_Recovered 84143528 (Vendor-specific raw value.) The raw value has different structure for different vendors and is often not meaningful as a decimal number.

197 Current_Pending_Sector 0 Count of 'unstable' sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it's written. However some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the 'Reallocation Event Count' (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.

198 Offline_Uncorrectable 0 The total count of uncorrectable errors when reading/writing a sector. A rise in the value of this attribute indicates defects of the disk surface and/or problems in the mechanical subsystem.

199 UDMA_CRC_Error_Count 563 The count of errors in data transfer via the interface cable as determined by ICRC (Interface Cyclic Redundancy Check).
Check and replace cable

240 Head_Flying_Hours 2144 Time spent during the positioning of the drive heads.

241 Total_LBAs_Written 149220277586 Total count of LBAs written.

242 Total_LBAs_Read 1218312875585 Total count of LBAs read. Some S.M.A.R.T. utilities will report a negative number for the raw value since in reality it has 48 bits rather than 32.

Definitivt att misstänka om inte diskarna ansluts direkt med varsin SATA/SAS-kabel individuellt direkt på drivern i kabinettet.

Att också prova strömförsörjningen av diskarna med andra vägar/kablar samt att ditt nätaggregat är tillräckligt bra och ny (i avseende risk för torkade kondingar).

Nätaggregat med hög rippel pga. att kondingarna börja torka och ha högre inre motstånd är något som de flesta inte har möjlighet att testa då ripplet kan vara högfrekvent i 100-tal kHz och lastreglering (tex. när läshuvudena rycker fram och tillbaka i diskarna och därmed drar korta strömpulser) med under och överslängar spänningsmässigt när strömmen ökar och minskar snabbt är på delar av ms och man behöver oscilloskop för att se sådant och inget som syns med multimeter. - till detta kunskap och erfarenheter att veta vad som är 'normalt' och när det avviker för mycket.

I de allra flesta fallen är att prova annan - helst ny - nätaggregat den enklaste felsökningsåtgärden för att utesluta kraftförsörjningsfel och förstås med denna ny kablage och inte återvinna den befintliga kablagen - inte en enda av dem.

Skulle nog säga att många diskproblem där diskar byts i onödan i tron att det är fel på disken och ofta mer än en gång i samma rigg, har i grunden med nätaggregat att göra (speciellt om det är krångel med diskar en efter en även vid garantibyte och/eller flera samtidigt), provar man med annan nätaggregat och problemen försvinner spårlöst, så har det med nätaggregatet att göra.

---

Om nummervärdet är 563 RAW i SMART post 199 (dec) så har du haft kabelfel - skall stå normalt '0' om man aldrig har haft fel i data-kablar och kontakter - men i ditt fall se om värdet ökar då denna post kan bara addera nya fel räknat över diskens livslängd och går inte att nollställa.

zpool status

  pool: bookshelf
  state: ONLINE
  scan: scrub repaired 0B in 0 days 00:00:09 with 0 errors on Sat Feb 19 21:46:02 2022
  config:

	NAME                        STATE     READ WRITE CKSUM
	bookshelf                   ONLINE       0     0     0
	  mirror-0                  ONLINE       0     0     0
	    wwn-0x50014ee266298dec  ONLINE       0     0     0
	    wwn-0x5000c500dc133a1d  ONLINE       0     0     0

  errors: No known data errors

# Lägger dit 3Gb filer och kör en scrub, och en massa  nya error....

zpool status

  pool: bookshelf
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: scrub repaired 3.50M in 0 days 00:00:21 with 0 errors on Sat Feb 19 22:35:38 2022
config:

	NAME                        STATE     READ WRITE CKSUM
	bookshelf                   DEGRADED     0     0     0
	  mirror-0                  DEGRADED     0     0     0
	    wwn-0x50014ee266298dec  DEGRADED     0     0    10  too many errors
	    wwn-0x5000c500dc133a1d  DEGRADED     0     0    19  too many errors

errors: No known data errors

zfs --version
zfs-0.8.3-1ubuntu12.13
zfs-kmod-0.8.3-1ubuntu12.13

Nu kommer jag med lite helvilda otänkta idéer(ingen särskild ordning trots numreringen, numrering enbart för återkoppling):

1. Testa byta VM miljö från Ubuntu till FreeBSD 11.x. Denna vet jag att den fungerar med Seagate ST3/X18, LSI och ESXi 5.0U1 trots att man gör en dum grej som jag gör och har ett RAID kort mellan(kan inte ställa om till IT-läge, så alla diskar blir istället enskilda RAID0:or som presenteras mot VM som RAW enheter(tappar S.M.A.R.T i VM).

2. Byta SAS/SATA port på HBA kort.

3. Byta HBA kort.

4. ?

Fråga:
Vilken ESXi version kör Du?

Såg en grej nu när jag verkligen läste långsamt:

Kan Du köra om processen som om från början, men direkt efter skrivning(eller under tiden skrivning sker), kör zpool status. För ZFS skall upptäcka fel direkt efter skrivning(autoverifiering). Om resultatet är 0 kontrollsummafel, gå vidare och läs in i något verktyg efter en omstart av servern dessa 3 GB och kolla återigen zpool status. Den skall nämligen själv upptäcka eventuella fel.

Jag är nämligen nyfiken på om felen dyker upp enbart efter en scrub eller direkt efter lagring/läsning.

Lägg gärna någon ZIP, RAR, 7Zip fil som är lite stor och som Du kan köra en verifiering manuellt på med hjälp av 3:e parts verktyg ifrån en omstartad dator(inget i cache). Nyfiken även här om filerna verkligen är skadade.

Jepp.
För det börjar lukta lite konstigt här.

ZFS verifierar kontrollsummor både efter skrivning samt vid läsning.
Alltså borde zpool status visa problemet med kontrollsumman även utan att köra scrub.

Testade detta för några år sedan när jag började köra ZFS första gången, då helt virtualiserat(ingen passthrough, bara rena VMDK för att skydda sig mot bitfel, inte diskfel).

Gick jag in med en HEX editor i vmdk filen(offline) på den ena vmdk(zfs mirror) för att ändra innehållet i en fil så lagade den allt själv, för när jag öppnade den faktiska filen när OS var i drift så var den som originalet(bara massa siffror 0-9 i korrekt ordning) och i zpool status såg man tydligt att den hade korrigerat samt loggat problemet.

För om Du bara får felet vid scrub och inte manuella kontroller upptäcker fel(ZIP, RAR, 7Zip) så börjar jag tro mjukvarufel eller (långsökt) värmeproblem på HBA kortet(flänsen lossnat?). Helt klart är ren spänning en förutsättning för allt OK, så nätdelen är fortfarande inte utesluten.

Beror på hur Du kör rsync. Jag kör själv rsync utan innehållskontroll för att få upp farten(jag kör enbart en 1-vägs synkronisering), således kontrolleras enbart filnamn(finns/finns ej) samt fildatum/tid/attribut för att se om en förändring har skett. Annars skall den kolla igenom någonstans runt 45+ TB var gång.

Bara på den !

Snart har Du hittat krypet(buggen) som springer i maskinen.

Väntar med spänning på resultat. Bra info att skriva ner inför framtiden.

Om inte direkt-på-metall lösningen ger vägledning så är detta min nästa teori:

Snart börjar jag tro att det är benen i CPU-sockeln eller CPU:n som är boven i dramat. Kan vara några PCI-e ben som inte är som de bör vara alltid, även om Du tidigare bytt PCI-e plats på HBA kortet.

Finns en intressant grej till Du kan göra innan Du ger dig på att demontera kylare+CPU:

1. Lagra lite data via problemservern.
2. Plocka ut diskarna, importera in dom i en annan fysisk server, kör scrub där, kolla resultatet.

En annan grej som jag glömt att fråga:
Vad är det exakt för prylar i burken?

a. Moderkort.
b. CPU(även antal).
c. HBA kort(fabrikat och modell, chip står redan i första inlägget).
d. Bakplan.
e. Nätdel(även antal).
f. RAM-minne(även antal).
g. Något annat instickskort i servern?

Du skulle kunna testa att installera typ TrueNAS på en USB-sticka så slipper du installera om allt på de vanliga lagringsenheterna.

Kan ha missat det men har du testat att koppla in diskarna till zpoolen direkt i SATA ingångarna på moderkortet istället för RAID-kortet? Eller bara skapa en zpool med en USB-sticka?

Personligen så misstänker jag antingen RAID-kortet eller RAM. Vad jag såg var det ända du gjorde med minnena att köra Memtest några timmar. Om felet finns kvar utan RAID-kortet så testa att rycka alla utom ett minne och se om det hjälper.

Felet är att efter att du har sparat data på zpoolen och kört en scrub får du checksum errors. Det verkar vara väldigt upprepningsbart. Testa helt enkelt att göra just det men med bara en minnessticka inkopplad.

Du skrev också att datorn stått väldigt svalt, det kan leda till fukt som gör att kontaktytor oxiderar. Bara en tanke.