Как бы починить «неломающуюся» fs: zfs? Есть файлы которые невозможно удалить.
Приветствую, уважаемое сообщество.
Занялся тут изучением zfs и прогоном скорости паковки разными алгоритмами. Вся работа была с SATA hdd подключенном через USB3 рэк. Идея была в прогоне этого винта на разных процессорах и замера скорости упаковки (отработки rsync на одних и тех же данных).
Всё сумбурно, и не всегда читал/фиксировал вывод команд. Они в общем то выводили в скриптах и в финале ошибки уже пролетали. После очередного цикла - заметил ошибку при rm -rf
Оставались неудаляемые файлы. Я даже и не представляю как это показать общественности.
Например
/usr/share/icons/matefaenza/mimetypes# ls -ld 64
drwxr-xr-x 2 root root 373 мая 27 2018 64
/usr/share/icons/matefaenza/mimetypes# rm -rf 64
rm: невозможно удалить '64': Каталог не пуст
/usr/share/icons/matefaenza/mimetypes# ls -l 64
ls: чтение каталога '64': Ошибка ввода/вывода
итого 0
Тут не файлы, тут пустые каталоги не удалить.
С файлами немного по другому:
/usr/share/icons/matefaenzadark/actions/16# ls -l stock_mail-send-receive.png
ls: невозможно получить доступ к 'stock_mail-send-receive.png': Некорректный обмен
И как теперь эти файлы/каталоги удалить? Неужели пул придется бэкапить и пересоздавать?
Дайте какие нибудь рекомендации для устранения этой ошибки.
P.S. При прогоне собралось тьма сырых даных, надо оформить в таблицах. Тупо rsync 64Gb данных занимал от 58 минут и до 11 часов и 27 минут
Без упаковки rsync отрабатывал от 59 минут (на BMAX B1 Pro) и до 73 минут (На Celeron E3400 @2.6GHz)
Упаковывалось до следующих значений:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
S1T1Archive 736G 164G 16.6M /S1T1Archive
S1T1Archive/gzip 37.7G 164G 37.7G /S1T1Archive/gzip
S1T1Archive/gzip-1 38.6G 164G 38.6G /S1T1Archive/gzip-1
S1T1Archive/gzip-9 37.6G 164G 37.6G /S1T1Archive/gzip-9
S1T1Archive/lz4 41.4G 164G 41.4G /S1T1Archive/lz4
S1T1Archive/lzjb 43.9G 164G 43.9G /S1T1Archive/lzjb
S1T1Archive/off 64.4G 164G 64.4G /S1T1Archive/off
S1T1Archive/off-copy 64.4G 164G 64.4G /S1T1Archive/off-copy
S1T1Archive/zle 60.8G 164G 60.8G /S1T1Archive/zle
S1T1Archive/zstd 37.9G 164G 37.9G /S1T1Archive/zstd
S1T1Archive/zstd-1 38.2G 164G 38.2G /S1T1Archive/zstd-1
S1T1Archive/zstd-19 36.9G 164G 36.9G /S1T1Archive/zstd-19
S1T1Archive/zstd-fast 39.5G 164G 39.5G /S1T1Archive/zstd-fast
S1T1Archive/zstd-fast-1 39.5G 164G 39.5G /S1T1Archive/zstd-fast-1
S1T1Archive/zstd-fast-10 42.2G 164G 42.2G /S1T1Archive/zstd-fast-10
S1T1Archive/zstd-fast-100 50.4G 164G 50.4G /S1T1Archive/zstd-fast-100
S1T1Archive/zstd-fast-1000 60.5G 164G 60.5G /S1T1Archive/zstd-fast-1000
off - Это собственно исходник который рсинкался в подразделы с разными алгоритмами.
P.S.
(240519)
Гугля, набрёл на хорошую статью о ручном восстановлении zfs, с описанием структур данных zfs: https://www.lissyara.su/articles/freebsd/file_system/zfs_recovery/