Trích xuất Tar từ băng nhiều tập trong khi tính toán shasums

Là một phần của hệ thống sao lưu, chúng tôi sao chép bộ dữ liệu zfs từ hệ thống TrueNAS sang một vài máy chủ dự phòng, một trong số đó đang chạy TrueNAS Scale và có ổ băng LTO-5 được kết nối. Thỉnh thoảng chúng tôi ghi một trong những nội dung của ảnh chụp nhanh chỉ đọc vào băng. Vì một số bộ dữ liệu này lớn, tar được sử dụng với cờ --multi-volume.

Trước khi sao lưu, sha256sums được tạo cho mọi tệp trong thư mục ảnh chụp nhanh. Một bản sao của tệp này được lưu trên máy chủ và cũng được ghi vào băng.

Sau đó, toàn bộ nội dung của ảnh chụp nhanh được ghi vào băng bằng cách sử dụng

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

Điều này đã phục vụ chúng tôi rất tốt, tuy nhiên, tôi muốn xác minh dữ liệu sau khi nó được ghi vào băng. Tôi muốn tránh phải trích xuất toàn bộ tập dữ liệu của các tệp vào một vị trí đầu mà nếu không sẽ cho phép chạy "sha256sum -c" vì máy chủ quy mô TrueNAS không có đủ dung lượng bổ sung cho một số tập dữ liệu được trích xuất. Thay vào đó tôi đã thử: -

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

Trường hợp tar-shasums.sh nằm dọc theo những dòng này:

#!/bin/bash

sha1=`sha1sum`
tiếng vang -n $sha1 | sed 's/ .*$//'
tiếng vang " $TAR_FILENAME"

Tuy nhiên, tôi đã gặp sự cố nếu tar trải dài trên hai băng. Khi tar đang đọc lại một tệp kéo dài hai băng, nó sẽ yêu cầu chèn tập tiếp theo và nhấn enter. Tuy nhiên, điều này sẽ báo lỗi khi thiết bị đang được sử dụng.

Có vẻ như "--to-command" vẫn đang hoạt động cho tệp đó, vì nó vẫn chưa nhận được tất cả dữ liệu để tạo shasum, nhưng nó cũng không thể kết thúc cho đến khi thay đổi băng, nhưng không thể thay đổi băng cho đến khi nó đã kết thúc rồi...

Hiện tại tôi tắt quá trình shasum, cho phép tar tiếp tục với băng tiếp theo nhưng có nghĩa là không thể xác minh một tệp bao gồm hai tập.Trừ khi tệp đó được giải nén và kiểm tra thủ công. Không lý tưởng.

Tôi đang mong đợi câu trả lời là không, nhưng, có cách nào giải quyết vấn đề này không? Có cách nào để tạo shasums không liên quan đến việc giải nén toàn bộ tar vào đĩa trước không? Hoặc, có cách nào để phá khóa trên/dev/nst0 để cho phép tar tiếp tục đọc từ băng mới được đưa vào mà không cần phải tắt shas256sum không?

Tôi đã xem nguồn tar tối qua và có vẻ như "--to-command" tạo ra một đường dẫn, sau đó nó sử dụng ngã ba để chạy tập lệnh và dẫn dữ liệu tệp vào đó.

Vì vậy, vấn đề là, fork khiến quy trình fork kế thừa tất cả các bộ mô tả tệp gốc bao gồm thiết bị /dev/nst0 mà tar đã mở. Sau đó, Tar đóng /dev/nst0 sẵn sàng để thay đổi phương tiện nhưng quá trình rẽ nhánh đang chờ thêm dữ liệu đường ống vẫn mở, do đó bế tắc.

Tôi đã giải quyết một phần vấn đề này bằng cách thay đổi tập lệnh mà nó chạy thành bộ mô tả luôn đóng/dev/nst0

THIẾT BỊ=/dev/nst0
tập tin=`lsof -p $$ | grep ${DEVICE} | awk '{in $4}'`
tệp=${tệp::-1}
eval "exec ${file}<&-"

Sau đó, chỉ có một quá trình "sh" dường như vẫn còn tồn tại trong bộ mô tả tệp. "fuser -u /dev/nst0" hiển thị điều này và như một giải pháp thay thế tạm thời, có thể sử dụng gdb để đóng nó sau đó phương tiện thay đổi và phần còn lại của tổng kiểm tra tạo chính xác.

gdb -p PID
p đóng(FD)

Tôi không chắc liệu có thể sử dụng ngã ba nhưng không chuyển tất cả các bộ mô tả tệp sang quy trình rẽ nhánh hay không nhưng có vẻ như đó sẽ là giải pháp cuối cùng.

Tôi sẽ cập nhật câu trả lời này nếu tôi tìm ra điều đó.