du hast eine korrupte Datei und weil sie korrupt ist, kann sie nicht angesprochen, also nicht gelöscht werden und weil sie nicht gelöscht werden kann, kann auch dein Verzeichnis nicht gelöscht werden, weil es nicht leer ist.
So verstehe ich die Meldungen.
Nun hast du geschrieben, dass dein Pool nur diese eine Platte enthält und ich sehe, dass es auch der ROOT-Pool ist.
Reparaturen an Dateisystemen sind immer problematisch und bei ZFS vielleicht unmöglich, denn scrub != fsck. Den Rat nach Backups, will ich hier gar nicht erst geben, denn der käme nun doch zu spät, oder doch beinahe.
Eine weitere Möglichkeit wäre noch, den Pool in ein anderes System einzubinden und dort zu untersuchen und gegebenenfalls Daten zu löschen.
Nicht korrupte Daten lassen sich so auch gut sichern.
So ein Sichern könnte zB auch innerhalb des Pools auf ein neu erstelltes Dataset erfolgen (wenn ausreichend Platz etc). Anschließendes Löschen des alten Datasets könnte vielleicht gelingen, wenn rm versagt, weil das auf einer ganz anderen Ebene statt findet.
Ebenso dd. Mit dd kannst eine Datei überschreiben und wenn wenn du die korrupte Datei nicht löschen kannst, gelingt es vielleicht, eine neue Datei mit einer Anzahl Nullen und gleichem Namen zu erzeugen. Die ist dann nicht korrupt und das Problem damit womöglich schon gelöst.
Insgesamt benutze ich vier externe Platten für meine regelmäßigen Sicherungen. Eine davon macht gelegentlich solche Sachen, wie von dir beschrieben. In meinem Fall ist das nicht schlimm. Ich möchte damit nur sagen, dass ich das Verhalten genau auf eine HW beschränken kann.
Wenn du dein Problem auch lösen kannst, ist aus meiner Sicht doch dringend ein review der HW a la mode
@gadean zu empfehlen.
