Extragerea gudronului din bandă cu mai multe volume în timp ce se calculează shasum

Ca parte a sistemului nostru de rezervă, replicăm seturile de date zfs dintr-un sistem TrueNAS pe câteva servere de rezervă, dintre care unul rulează TrueNAS Scale și are o unitate de bandă LTO-5 conectată. Ocazional scriem pe bandă unul dintre conținutul instantaneului doar pentru citire. Deoarece unele dintre aceste seturi de date sunt mari, tar este folosit cu indicatorul --multi-volume.

Înainte de backup, sumele sha256 sunt generate pentru fiecare fișier din directorul de instantanee. O copie a acestui fișier este păstrată pe server și, de asemenea, scrisă pe bandă.

După aceasta, întregul conținut al instantaneului este scris pe bandă folosind

  tar --acls --xattrs --spares --label="SomeLabel" --multi-volume -cvpf /dev/nst0 *

Acest lucru ne-a servit bine, totuși, doresc să verific datele după ce au fost scrise pe bandă. Vreau să evit nevoia de a extrage întregul set de date de fișiere într-o locație de zero, care altfel ar permite rularea „sha256sum -c”, deoarece serverul de scară TrueNAS nu are suficient spațiu suplimentar pentru extragerea unor seturi de date. In schimb am incercat:-

  tar --multi-volume -xf /dev/nst0 --to-command=tar-shasums.sh | tee verify-datasetname.sha25sum

Unde tar-shasums.sh este pe aceste linii:

#!/bin/bash

sha1=`sha1sum`
echo -n $sha1 | sed 's/ .*$//'
ecou „ $TAR_FILENAME”

Totuși, am întâlnit o problemă dacă gudronul se întinde pe două benzi. Când tar este în mijlocul citirii înapoi a unui fișier care se întinde pe două benzi, acesta va cere ca următorul volum să fie inserat și va fi apăsat enter. Cu toate acestea, aceasta va eroa pe măsură ce dispozitivul este în uz.

Se pare că „--to-command” este încă activ pentru acel fișier, deoarece nu a primit încă toate datele pentru a produce shasum, dar nici nu se poate termina până când banda nu este schimbată, dar banda nu poate fi schimbată până când s-a terminat...

În prezent, opresc procesul shasum, care permite tarului să continue cu următoarea bandă, dar înseamnă că un fișier care acoperă cele două volume nu poate fi verificat.Cu excepția cazului în care acel fișier este extras și verificat manual. Nu este ideal.

Mă aștept la un nu, dar există vreo cale de a evita asta? Vreo modalitate de a genera shasum-uri care nu implică mai întâi extragerea întregului gudron pe disc? Sau, vreo modalitate de a rupe blocajele pe /dev/nst0 pentru a permite tarului să continue citirea de pe banda nou introdusă fără a fi nevoie să omorâți shas256sum?

Am aruncat o privire la sursa tar aseară și se pare că „--to-command” creează o conductă, apoi folosește fork pentru a rula script-ul și îi trimite datele fișierului.

Deci problema este că fork face ca procesul forked să moștenească toți descriptorii fișierelor părinți care includ dispozitivul /dev/nst0 pe care tar îl are deschis. Tar închide apoi /dev/nst0 gata pentru schimbarea media, dar procesul bifurcat care așteaptă mai multe date canalizate încă îl are deschis, prin urmare, blocaj.

Am rezolvat parțial acest lucru schimbând scriptul pe care îl rulează pentru a închide întotdeauna descriptorul /dev/nst0

DEVICE=/dev/nst0
fisier=`lsof -p $$ | grep ${DEVICE} | awk '{print $4}''
fișier=${fișier::-1}
eval "exec ${file}<&-"

Există atunci doar un proces „sh” care pare să se agațe încă de descriptorul fișierului. „fuser -u /dev/nst0” arată acest lucru și, ca o soluție temporară, este posibil să utilizați gdb pentru a-l închide, după care media se schimbă și restul sumelor de verificare se generează corect.

gdb -p PID
p închide (FD)

Nu sunt sigur dacă este posibil să folosiți fork, dar să nu treceți toți descriptorii de fișiere la procesul forked, dar asta se pare că ar fi soluția finală.

Voi actualiza acest răspuns dacă îmi dau seama.