From nobody@FreeBSD.org  Tue Dec 14 07:02:33 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 09A56106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Dec 2010 07:02:33 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id EC9B48FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Dec 2010 07:02:32 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id oBE72Ww1016726
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Dec 2010 07:02:32 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id oBE72WUo016725;
	Tue, 14 Dec 2010 07:02:32 GMT
	(envelope-from nobody)
Message-Id: <201012140702.oBE72WUo016725@red.freebsd.org>
Date: Tue, 14 Dec 2010 07:02:32 GMT
From: Hiroshi Fujishima <hirobo@tonteki.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         153142
>Category:       bin
>Synopsis:       [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-fs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 14 07:10:11 UTC 2010
>Closed-Date:    
>Last-Modified:  Sun Aug 19 07:02:29 UTC 2012
>Originator:     Hiroshi Fujishima
>Release:        8.1-RELEASE
>Organization:
>Environment:
FreeBSD backup8y.sakura.ad.jp 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
1. filesystem is zfs
2. snapdir property is visible
3. top directory of file system has .a file.

with above condition, ls -l outputs `ls: ./.zfs: Operation not supported'

>How-To-Repeat:
backup8y# zfs create -o mountpoint=/test -o snapdir=visible tank/test
backup8y# ls -l /test
total 0
dr-xr-xr-x  3 root  wheel  3 Dec 14 15:46 .zfs
backup8y# touch /test/.a
backup8y# ls -l /test
total 1
-rw-r--r--  1 root  wheel  0 Dec 14 15:46 .a
ls: /test/.zfs: Operation not supported
dr-xr-xr-x  3 root  wheel  3 Dec 14 15:46 .zfs


>Fix:


>Release-Note:
>Audit-Trail:

From: Bruce Cran <bruce@cran.org.uk>
To: Hiroshi Fujishima <hirobo@tonteki.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not
 supported'
Date: Tue, 14 Dec 2010 19:54:21 +0000

 On Tue, 14 Dec 2010 07:02:32 GMT
 Hiroshi Fujishima <hirobo@tonteki.org> wrote:
 
 > with above condition, ls -l outputs `ls: ./.zfs: Operation not
 > supported'
 
 I can confirm that this occurs on HEAD too: the .zfs directory can't be
 listed but directories under it can.
 
 -- 
 Bruce Cran

From: Jaakko Heinonen <jh@FreeBSD.org>
To: Hiroshi Fujishima <hirobo@tonteki.org>
Cc: Bruce Cran <bruce@cran.org.uk>, bug-followup@FreeBSD.org,
	trasz@FreeBSD.org
Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not
 supported'
Date: Fri, 14 Jan 2011 11:00:50 +0200

 Hi,
 
 On 2010-12-14, Hiroshi Fujishima wrote:
 > >Description:
 > 1. filesystem is zfs
 > 2. snapdir property is visible
 > 3. top directory of file system has .a file.
 > 
 > with above condition, ls -l outputs `ls: ./.zfs: Operation not supported'
 > 
 > >How-To-Repeat:
 > backup8y# zfs create -o mountpoint=/test -o snapdir=visible tank/test
 > backup8y# ls -l /test
 > total 0
 > dr-xr-xr-x  3 root  wheel  3 Dec 14 15:46 .zfs
 > backup8y# touch /test/.a
 > backup8y# ls -l /test
 > total 1
 > -rw-r--r--  1 root  wheel  0 Dec 14 15:46 .a
 > ls: /test/.zfs: Operation not supported
 > dr-xr-xr-x  3 root  wheel  3 Dec 14 15:46 .zfs
 
 ls(1) detects from the first file in the listing if the file system
 supports ACLs and assumes that all files on the same file system support
 ACLs. The ".zfs" directory is special and doesn't support ACLs. Thus
 ls(1) prints an error message for acl_get_link_np(3) failure.
 
 Also, if the ".zfs" directory is the first entry of a listing, ls(1)
 assumes that files on the same file system don't have ACLs and doesn't
 print '+' after mode.
 
 -- 
 Jaakko

From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org>
To: Jaakko Heinonen <jh@FreeBSD.org>
Cc: Hiroshi Fujishima <hirobo@tonteki.org>,
 Bruce Cran <bruce@cran.org.uk>,
 bug-followup@FreeBSD.org
Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
Date: Fri, 14 Jan 2011 10:07:02 +0100

 Wiadomo=B6=E6 napisana przez Jaakko Heinonen w dniu 2011-01-14, o godz. =
 10:00:
 > On 2010-12-14, Hiroshi Fujishima wrote:
 >>> Description:
 >> 1. filesystem is zfs
 >> 2. snapdir property is visible
 >> 3. top directory of file system has .a file.
 >>=20
 >> with above condition, ls -l outputs `ls: ./.zfs: Operation not =
 supported'
 >>=20
 >>> How-To-Repeat:
 >> backup8y# zfs create -o mountpoint=3D/test -o snapdir=3Dvisible =
 tank/test
 >> backup8y# ls -l /test
 >> total 0
 >> dr-xr-xr-x  3 root  wheel  3 Dec 14 15:46 .zfs
 >> backup8y# touch /test/.a
 >> backup8y# ls -l /test
 >> total 1
 >> -rw-r--r--  1 root  wheel  0 Dec 14 15:46 .a
 >> ls: /test/.zfs: Operation not supported
 >> dr-xr-xr-x  3 root  wheel  3 Dec 14 15:46 .zfs
 >=20
 > ls(1) detects from the first file in the listing if the file system
 > supports ACLs and assumes that all files on the same file system =
 support
 > ACLs. The ".zfs" directory is special and doesn't support ACLs. Thus
 > ls(1) prints an error message for acl_get_link_np(3) failure.
 >=20
 > Also, if the ".zfs" directory is the first entry of a listing, ls(1)
 > assumes that files on the same file system don't have ACLs and doesn't
 > print '+' after mode.
 
 I guess the easiest way to fix this would be to add "dummy" ACL support
 for ".zfs" directory - that is, to zfsctl_ops_root[], if I'm reading =
 this
 correctly.
 
 --
 If you cut off my head, what would I say?  Me and my head, or me and my =
 body?
 
Responsible-Changed-From-To: freebsd-bugs->araujo 
Responsible-Changed-By: araujo 
Responsible-Changed-When: Mon Apr 16 03:53:31 UTC 2012 
Responsible-Changed-Why:  
I'm performing some tests using ZFS + NFS and I found the same issue on 
FreeBSD 8, but not on FreeBSD-10, I'm gonna performe more debugs to 
check how solve it on version 8. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=153142 
State-Changed-From-To: open->closed 
State-Changed-By: araujo 
State-Changed-When: Mon Apr 16 06:28:17 UTC 2012 
State-Changed-Why:  
It was solved on PR number 150544. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=153142 
State-Changed-From-To: closed->open 
State-Changed-By: pjd 
State-Changed-When: wto 31 lip 2012 07:30:41 UTC 
State-Changed-Why:  
How exactly was it fixed? Can you point me at revision that was suppose 
to fix it? You are not able to reproduce it after the fix went in? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=153142 
State-Changed-From-To: open->feedback 
State-Changed-By: araujo 
State-Changed-When: Sun Aug 19 06:59:21 UTC 2012 
State-Changed-Why:  
Hi Pjd and Hirobo,

I got two different problems related with almost the same issue, but all of my problems were related when I tried to access .zfs via NFS, even with a simple 'ls -a'.

The patch bellow fix one part of the issue. And also I have another patch that implement a dummy NFSv4 ACL for .zfs pseudo-directory, but as I spoke with PJD, maybe I'm not able to share this patch.

Those two patchs mentioned above, right now I'm using them on FreeBSD-9.0-RELEASE, and I can't reproduce the problem, maybe the dummy NFSv4 ACL does more than I thought, and close this PR was my mistake.

The patch below is related when perform the command 'ls -a /mnt/.zfs/' via a shared NFS pool. I made tests using Linux, Mac and FreeBSD, in all of them it works and does not crash anymore. However with the FreeBSD-CURRENT it does not happen, maybe because of the NFSv4.

So, sorry to close the PR.

State-Changed-From-To: feedback->open 
State-Changed-By: araujo 
State-Changed-When: Sun Aug 19 07:02:03 UTC 2012 
State-Changed-Why:  
- Put it back to the freebsd-fs pool. 


Responsible-Changed-From-To: araujo->freebsd-fs 
Responsible-Changed-By: araujo 
Responsible-Changed-When: Sun Aug 19 07:02:03 UTC 2012 
Responsible-Changed-Why:  
- Put it back to the freebsd-fs pool. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=153142 
>Unformatted:
