Bug 1027180

Summary:	btrfs-progs: btrfs subvolume get-default <mnt> return 1 even if command exit with no error
Product:	Red Hat Enterprise Linux 7	Reporter:	Eryu Guan <eguan>
Component:	btrfs-progs	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Filesystem QE <fs-qe>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	eguan, esandeen
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-02-19 02:33:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Eryu Guan 2013-11-06 10:35:33 UTC

Description of problem:
[root@hp-dl388eg8-01 mount]# mount | grep /mnt/scratch
/dev/loop0 on /mnt/scratch type btrfs (rw,relatime,seclabel,space_cache)
[root@hp-dl388eg8-01 mount]# btrfs subvolume get-default /mnt/scratch
ID 5 (FS_TREE)
[root@hp-dl388eg8-01 mount]# echo $?
1   <==== should be 0

Seems like a regression, I haven't seen this before.

Version-Release number of selected component (if applicable):
btrfs-progs-0.20.rc1.20130917git194aa4a-1.el7

How reproducible:
always

Steps to Reproduce:
1. mount a btrfs at /mnt
2. btrfs subvolume get-default /mnt
3. echo $?

Actual results:
return value is 1

Expected results:
return value should be 0

Additional info:

Comment 2 Eric Sandeen 2014-02-18 20:37:46 UTC

Eryu, since you have this in an RHTS test, do you know if it's still failing w/ the btrfs-progs rebase?

Also, moving to rhel7.1 for now, this just isn't that critical.

Thanks,
-Eric

Comment 4 Eryu Guan 2014-02-19 02:33:17 UTC

It's fixed in btrfs-progs-3.12-4.el7, closed it as CURRENTRELEASE.