Date: Fri, 4 May 2012 12:21:53 +0200 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-fs@FreeBSD.org Subject: Re: ls NFSv4 is not perfect Message-ID: <429AC809-E1CE-4107-8FF2-19FD3C7D58BF@FreeBSD.org> In-Reply-To: <4F78C33D.7080708@FreeBSD.org> References: <4F78C33D.7080708@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Wiadomo=B6=E6 napisana przez Andriy Gapon w dniu 1 kwi 2012, o godz. = 23:06: > It seems that aclmode() function in bin/ls/print.c caches ACL support = properties > of a filesystem. Unfortunately this optimization doesn't always work. > An example: a UFS directory unionfs-mounted over ZFS directory. Files = that > reside in ZFS and are not shadowed by UFS do have ACL_NFS4 stuff, = files in UFS > don't have it. > An example of ls -l behavior in this case: > -rw-r--r-- 1 mrtg mrtg 3881 1 Apr 06:55 corevoltages-year.png > -rw-r--r-- 1 mrtg mrtg 5605 1 Apr 06:55 userload-year.png > -rw-r--r-- 1 mrtg mrtg 2782 1 Apr 06:55 uptime-year.png > ls: /var/www/stats/mrtg/cpufreq.old: Operation not supported > -rw-r--r-- 1 mrtg mrtg 61200 1 Apr 23:00 cpufreq.old > ls: /var/www/stats/mrtg/irqrate.old: Operation not supported > -rw-r--r-- 1 mrtg mrtg 55538 1 Apr 23:00 irqrate.old > ls: /var/www/stats/mrtg/cpuload.old: Operation not supported > -rw-r--r-- 1 mrtg mrtg 58826 1 Apr 23:00 cpuload.old > ls: /var/www/stats/mrtg/cpuload2.old: Operation not supported >=20 > The older files are in ZFS, the newer are in UFS. > ktrace, just in case: > CALL __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000) > NAMI "/var/www/stats/mrtg/uptime.html" > RET __acl_get_link 0 > CALL write(0x1,0x8010be000,0x3b) > ... > CALL __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000) > NAMI "/var/www/stats/mrtg/xxx" > RET __acl_get_link -1 errno 45 Operation not supported >=20 > Not sure what's the best approach here. > Maybe just silence this particular error code? Situation is more complicated than that - there is an optimization in ls(1) that makes it assume that a given filesystem supports only one ACL brand, either POSIX.1e or NFS4, and it's determined using the first file ls(1) will find. So, in situation above, you'll get POSIX ACLs for some files and ENOTSUPP for others, _or_ ENOTSUPP for some files and NFS4 ACLs for others, depending on sorting order. Same assumption is found in several other tools, such as cp(1). I think we should leave it as it is - this ENOTSUPP _is_ an error; silencing it would result in ls(1) indicating different permissions that are actually being enforced. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429AC809-E1CE-4107-8FF2-19FD3C7D58BF>