Project

General

Profile

Bug #5521

zfs hold with empty tag prints the wrong error message

Added by Josef Sipek about 5 years ago. Updated about 5 years ago.

Status:
New
Priority:
Low
Assignee:
Category:
zfs - Zettabyte File System
Start date:
2015-01-10
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
needs-triage

Description

The hold ioctl handler returns EINVAL in one of two
cases:

  1. the hold tag is empty (new)
  2. user wanted to put a hold on something that's not a snapshot (existing)

Sadly, the ioctl return value makes its way to libzfs (zfs_hold_nvl), which does what libzfs does - prints an error message.

http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libzfs/common/libzfs_dataset.c#4305

It of course assumes that we got an EINVAL because of case #2 and so the user sees:

"operation not applicable to datasets of this type"

My best idea is to add a empty-tag check to libzfs.

A way to test:

$ zfs hold '' storage/upstream@9e835c7628dd0e7764a8341a1774a878dc0b024f
cannot hold: operation not applicable to datasets of this type

Related issues

Follows illumos gate - Bug #5515: dataset user hold doesn't reject empty tagsClosed2015-01-08

Actions

History

#1

Updated by Shruti Sampat about 5 years ago

  • Assignee set to Shruti Sampat
#2

Updated by Josef Sipek about 5 years ago

Cool to see someone pick this up.

Beware, in order to see the EINVAL, you'll have to apply the patch from:

http://31bits.net/illumos/cr/5515-dataset-user-hold-doesnt-reject-empty-tags/

I filed the RTI, but the advocates requested more testing (zfstests) - which got delayed.

Also available in: Atom PDF