openzfs/zfs

zfs holds -r does not work on non-snapshot datasets

Open

#9.822 geöffnet am 8. Jan. 2020

Auf GitHub ansehen
 (3 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C (1.703 Forks)batch import
Type: Defectgood first issue

Repository-Metriken

Stars
 (9.908 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 5T 21h) (62 gemergte PRs in 30 T)

Beschreibung

System information

Type Version/Name
Distribution Name Arch Linux
Distribution Version rolling
Linux Kernel 5.4.6
Architecture x86_64
ZFS Version 0.8.2-1
SPL Version 0.8.2-1

Describe the problem you're observing

If trying to list all of the holds on all of the snapshots on a dataset, I would expect zfs holds -r [dataset] to list, per snapshot, all of the holds. On FreeBSD 12.1 this works as expected. However, on ZFS on Linux it just says "not a snapshot" and lists nothing.

Describe how to reproduce the problem

  • Create a snapshot on a dataset
  • Create a hold on that snapshot
  • Run zfs holds -r [dataset]@[snapshot] and observe the hold
  • Run zfs holds -r [dataset] and observe the error

Include any warning/errors/backtraces from the system logs

N/A

Contributor Guide

Research-Richtung
Untersuchen Sie die Implementierung des Befehls 'zfs holds r' im ZFS Quellcode, insbesondere in der Datei 'cmd/zfs/zfs main.c'. Das Problem erwähnt, dass das rekursive Flag bei Nicht Snapshot Datasets nicht funktioniert, während es unter FreeBSD funktioniert. Suchen Sie, wie das ' r' Flag verarbeitet wird und wie das Dataset Argument behandelt wird. Vergleichen Sie die Linux und FreeBSD Implementierungen, falls verfügbar. Überprüfen Sie die Manpage auf das erwartete Verhalten und prüfen Sie, ob es vorhandene Kommentare oder Codekommentare zu dieser Diskrepanz gibt. Das Problem hat keine verknüpften PRs, daher könnte die Behebung das Ändern der Argumentverarbeitung oder Iterationslogik umfassen, um Snapshots einzuschließen, wenn das ' r' Flag verwendet wird.
Tech Stack
c
Domain
cli
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
4
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Veraltet
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
Git
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
30