Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/11 08:35, Steve Wills wrote: On 03/06/11 04:22, Edward Tomasz NapieraBa wrote: Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11: [..] Thanks for your work on this, I'm very happy to have ZFS v28. I just updated my -CURRENT system from a snapshot from about a month ago to code from today. I have 3 pools and one of them is for ports tinderbox. I only upgraded that pool. When I try to build something using tinderbox, I get this error: cp: failed to set acl entries for /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation not supported What does mount show? /dev/md4 12186190 332724 11853466 3% /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD Sorry, I forgot about the mdmfs hacks I had in my local tinderd. Without them, it works fine. So the problem seems to be in mfs rather than zfs. I should have said mdmfs, but all that's doing is running mdconfig and newfs for me. I've reproduced the issue without mdmfs: % mdconfig -a -t swap -s 12G -u 4 % newfs -m 0 -o time /dev/md4 [...] % mount /dev/md4 /tmp/foobar % cp -p /usr/local/tinderbox/scripts/lib/buildscript /tmp/foobar cp: failed to set acl entries for /tmp/foobar/buildscript: Operation not supported Without -p it works fine. FWIW: % getfacl /usr/local/tinderbox/scripts/lib/buildscript # file: /usr/local/tinderbox/scripts/lib/buildscript # owner: root # group: wheel owner@:--:--:deny owner@:rwxp---A-W-Co-:--:allow group@:-w-p--:--:deny group@:r-x---:--:allow everyone@:-w-p---A-W-Co-:--:deny everyone@:r-x---a-R-c--s:--:allow Any suggestions on where the problem could be? Thanks, Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNc52WAAoJEPXPYrMgexuhayoH/ROak0Vj2Ezh3t0ViqeZ8n/v Pa60x/MDvHcoqtEUM6CQulvf88pAjat07JCwoZKf2qlNgZgrcoK5gPjSeDsN+9jW LJxuFIyTOAmNxVC3FJgRuynTv06nAXDJu9f8psYVQS8EW56UQ9gmvKWNA3v80w2F bre2qzHneA42+5ZvVLnK6sSMJ2IBoyk9F1FXamUsP74TKygDL3iijatWWROJ+lQ+ HdY+TnmKEkZcXbl5qhya4etpPOxKcuTCD/VqYvUJXqkseIny9SE60xVhGyQWlDkU xEtjHQL8oRkc5CTHpCVJQMFiVGNFpBKutZq56wAaG0xgcDuWhvHJ3hcv8m93VYg= =c86J -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
On Sun, Mar 06, 2011 at 09:43:34AM -0500, Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 08:35, Steve Wills wrote:
On 03/06/11 04:22, Edward Tomasz NapieraBa wrote:
Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11:
[..]
Thanks for your work on this, I'm very happy to have ZFS v28. I just
updated my -CURRENT system from a snapshot from about a month ago to
code from today. I have 3 pools and one of them is for ports tinderbox.
I only upgraded that pool. When I try to build something using
tinderbox, I get this error:
cp: failed to set acl entries for
/usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation not
supported
What does mount show?
/dev/md4 12186190 332724 11853466 3%
/usr/local/tinderbox/9-CURRENT-amd64-FreeBSD
Sorry, I forgot about the mdmfs hacks I had in my local tinderd. Without
them, it works fine. So the problem seems to be in mfs rather than zfs.
I should have said mdmfs, but all that's doing is running mdconfig and
newfs for me. I've reproduced the issue without mdmfs:
% mdconfig -a -t swap -s 12G -u 4
% newfs -m 0 -o time /dev/md4
[...]
% mount /dev/md4 /tmp/foobar
% cp -p /usr/local/tinderbox/scripts/lib/buildscript /tmp/foobar
cp: failed to set acl entries for /tmp/foobar/buildscript: Operation not
supported
Without -p it works fine. FWIW:
% getfacl /usr/local/tinderbox/scripts/lib/buildscript
# file: /usr/local/tinderbox/scripts/lib/buildscript
# owner: root
# group: wheel
owner@:--:--:deny
owner@:rwxp---A-W-Co-:--:allow
group@:-w-p--:--:deny
group@:r-x---:--:allow
everyone@:-w-p---A-W-Co-:--:deny
everyone@:r-x---a-R-c--s:--:allow
Any suggestions on where the problem could be?
At first glance it looks like acl_set_fd_np(3) isn't working on an
md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
should be able to reproduce the problem by doing a setfacl on something
in /tmp/foobar.
Looking through src/bin/cp/utils.c, this is the code:
420 if (acl_set_fd_np(dest_fd, acl, acl_type) 0) {
421 warn(failed to set acl entries for %s, to.p_path);
422 acl_free(acl);
423 return (1);
424 }
EOPNOTSUPP for acl_set_fd_np(3) is defined as:
[EOPNOTSUPP] The file system does not support ACL retrieval.
This would be referring to the destination filesystem.
Looking through the md(4) source for references to EOPNOTSUPP, we do
find some references:
$ egrep -n -r EOPNOTSUPP|ENOTSUP /usr/src/sys/dev/md
/usr/src/sys/dev/md/md.c:423: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:475: error = EOPNOTSUPP;
/usr/src/sys/dev/md/md.c:523: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:601: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:731: error = EOPNOTSUPP;
Line 423 is within mdstart_malloc(), and it returns EOPNOTSUPP on any
BIO operation other than READ/WRITE/DELETE. Line 475 is a continuation
of that.
Line 508 is within mdstart_vnode(), behaving effectively the same as
line 423. Line 601 is within mdstart_swap(), behaving effectively the
same as line 423.
Line 731 is within md_kthread(), and indicates only BIO operation
BIO_GETATTR is supported. This would not be an ACL attribute thing,
but rather getting attributes of the backing device itself. The code
hints at that:
722 if (bp-bio_cmd == BIO_GETATTR) {
723 if ((sc-fwsectors sc-fwheads
724 (g_handleattr_int(bp, GEOM::fwsectors,
725 sc-fwsectors) ||
726 g_handleattr_int(bp, GEOM::fwheads,
727 sc-fwheads))) ||
728 g_handleattr_int(bp, GEOM::candelete, 1))
729 error = -1;
730 else
731 error = EOPNOTSUPP;
732 } else {
This leaves me with some ideas; just tossing them out here...
1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)? Try using mdconfig -t malloc -o reserve
instead, temporarily anyway.
2. Are you absolutely 100% sure the kernel you're using was built
with options UFS_ACL defined in it? Doing a strings -a
/boot/kernel/kernel | grep UFS_ACL should suffice.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-current@freebsd.org mailing list
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/11 10:37, Jeremy Chadwick wrote:
At first glance it looks like acl_set_fd_np(3) isn't working on an
md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
should be able to reproduce the problem by doing a setfacl on something
in /tmp/foobar.
Looking through src/bin/cp/utils.c, this is the code:
420 if (acl_set_fd_np(dest_fd, acl, acl_type) 0) {
421 warn(failed to set acl entries for %s, to.p_path);
422 acl_free(acl);
423 return (1);
424 }
EOPNOTSUPP for acl_set_fd_np(3) is defined as:
[EOPNOTSUPP] The file system does not support ACL retrieval.
This would be referring to the destination filesystem.
Looking through the md(4) source for references to EOPNOTSUPP, we do
find some references:
$ egrep -n -r EOPNOTSUPP|ENOTSUP /usr/src/sys/dev/md
/usr/src/sys/dev/md/md.c:423: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:475: error = EOPNOTSUPP;
/usr/src/sys/dev/md/md.c:523: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:601: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:731: error = EOPNOTSUPP;
Line 423 is within mdstart_malloc(), and it returns EOPNOTSUPP on any
BIO operation other than READ/WRITE/DELETE. Line 475 is a continuation
of that.
Line 508 is within mdstart_vnode(), behaving effectively the same as
line 423. Line 601 is within mdstart_swap(), behaving effectively the
same as line 423.
Line 731 is within md_kthread(), and indicates only BIO operation
BIO_GETATTR is supported. This would not be an ACL attribute thing,
but rather getting attributes of the backing device itself. The code
hints at that:
722 if (bp-bio_cmd == BIO_GETATTR) {
723 if ((sc-fwsectors sc-fwheads
724 (g_handleattr_int(bp, GEOM::fwsectors,
725 sc-fwsectors) ||
726 g_handleattr_int(bp, GEOM::fwheads,
727 sc-fwheads))) ||
728 g_handleattr_int(bp, GEOM::candelete, 1))
729 error = -1;
730 else
731 error = EOPNOTSUPP;
732 } else {
Thanks for the investigation! So this seems to be a bug in md? That's
too bad, I was enjoying using it to make my tinderbox builds faster.
This leaves me with some ideas; just tossing them out here...
1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)? Try using mdconfig -t malloc -o reserve
instead, temporarily anyway.
Seems to be the same.
2. Are you absolutely 100% sure the kernel you're using was built
with options UFS_ACL defined in it? Doing a strings -a
/boot/kernel/kernel | grep UFS_ACL should suffice.
Yep, it does:
% strings -a /boot/kernel/kernel | grep UFS_ACL
options UFS_ACL
(My kernel config is just include GENERIC then a bunch of nooptions
for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBAgAGBQJNc7DxAAoJEPXPYrMgexuh3gsH/0L474FitZMdLLrTLiDiU7jR
D+9syg0boUYcWbv6pA1j1r8LvXMrw0rIxvZOPB4BauY/u8nL5n0YgDgv7tjb69+D
n/m7ce6r1tm6JtBSl/d+MIYfmcnj1E9B8ibgeGwPApKnhe4lmmyLpFHW98tcU1EL
Be+koxDiaKloryyfHrlcIfmSmXMUZ8lP7MFHfFeS39KbE+sf7xXHHLjFE7bcPSi4
qKyBFDcw/ykRjsrM3+YDIanhLUHg8ZjKhlrzbPUgMpzlXXe2QbmLkQELa9SmhVzH
juYywb7JOe5uHuefFQxnTLkSWuDjTlxLW6M+FuNEDejfA91sGIil7m+1nMcdCFg=
=nsSt
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
On 6 Mar 2011, at 16:30, Jeremy Chadwick wrote: 2. Are you absolutely 100% sure the kernel you're using was built with options UFS_ACL defined in it? Doing a strings -a /boot/kernel/kernel | grep UFS_ACL should suffice. Yep, it does: % strings -a /boot/kernel/kernel | grep UFS_ACL options UFS_ACL (My kernel config is just include GENERIC then a bunch of nooptions for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.) Cool, good to rule out the obvious. Thanks. The only other thing I can think of off the top of my head would be to ktrace -t+ -i the cp -p, then provide output of kdump -s -t+ after. I wouldn't say go about this quite yet (it may not even help determine what's going on); maybe wait for Robert to take a look first. It would help if I actually added Robert to the CC list, wouldn't it? :-) There's a lot of information in that post, perhaps it would be useful for someone to clarify what's going on exactly. If you're using ACLs on UFS, have you turned them on using tunefs? What flavour of ACLs are you using -- POSIX.1e or NFSv4? Robert___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/11 11:30, Jeremy Chadwick wrote: On Sun, Mar 06, 2011 at 08:23:42AM -0800, Jeremy Chadwick wrote: On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote: Sorry, I should have been more clear -- my investigation wasn't to determine if the issue you're reporting was a bug or not, but more along the lines of hmm, where is userland getting EOPNOTSUPP from in the kernel in this situation? It could be that some piece hasn't been implemented somewhere yet (more an incomplete than a bug :-) ). I tend to trace source the way I did above in hopes that someone (kernel dev, etc.) will chime in and go Oh, yes, THAT... let me tell you about that! It's also for educational purposes; I figure sharing the innards along with some simple descriptions might help people feel more comfortable (vs. thinking everything is a black box; don't let the magic smoke out!). Sometimes digging through the code helps. Definitely. I had started looking at cp(1) source, but got a bit lost. This leaves me with some ideas; just tossing them out here... 1. Maybe/somehow this is caused by swap being used as the backing type/store for md(4)? Try using mdconfig -t malloc -o reserve instead, temporarily anyway. Seems to be the same. I'm not too surprised, but at least that rules out swap vs. non-block-device stuff being somehow responsible. I'm not a user of ACLs myself, but Robert Watson might know what's up with this, or where to go looking. I've CC'd him here. 2. Are you absolutely 100% sure the kernel you're using was built with options UFS_ACL defined in it? Doing a strings -a /boot/kernel/kernel | grep UFS_ACL should suffice. Yep, it does: % strings -a /boot/kernel/kernel | grep UFS_ACL options UFS_ACL (My kernel config is just include GENERIC then a bunch of nooptions for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.) Cool, good to rule out the obvious. Thanks. The only other thing I can think of off the top of my head would be to ktrace -t+ -i the cp -p, then provide output of kdump -s -t+ after. I wouldn't say go about this quite yet (it may not even help determine what's going on); maybe wait for Robert to take a look first. It would help if I actually added Robert to the CC list, wouldn't it? :-) That's OK, kib@ enlightened me (via IRC) that the issue is that I failed to enable NFSv4 ACLs on the FS. I had tried this, but somehow got an error, and then when I tried again I had the wrong ACL type (POSIX.1e). Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNc7mdAAoJEPXPYrMgexuhhZUIAId0nmh4YTJbjzv3NDmxXVt3 16ZIx+wOQON9Sln0vrpKIDJGk95KzvuLnbVBPg7Oxhaa11llkEeYFFqMEVWn6Esa hqwDe5yYJYWWyF7ulCmHDbAE2gEF5q2rVy0KrV+aI9x5DLeB607dpmZqVV6TeQky mQb1zOcw165galYhI3S4juPK6z5nq5pnTc+l05590CcAkWtxOFwQjlDZiQtrxdg2 YhFhtrMeGubRdKtJyG0r17kJzlGCBwIYBg7SgnmORVB64W0N0zkVcC+ZrIhioR6Z FoucxqelZ4VDt6IlmxZ3DzTNUGKWulCeCrus8+lDBPL1M92AfFgMF89i5n0Ot8Y= =302p -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote:
On 03/06/11 10:37, Jeremy Chadwick wrote:
At first glance it looks like acl_set_fd_np(3) isn't working on an
md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
should be able to reproduce the problem by doing a setfacl on something
in /tmp/foobar.
Looking through src/bin/cp/utils.c, this is the code:
420 if (acl_set_fd_np(dest_fd, acl, acl_type) 0) {
421 warn(failed to set acl entries for %s, to.p_path);
422 acl_free(acl);
423 return (1);
424 }
EOPNOTSUPP for acl_set_fd_np(3) is defined as:
[EOPNOTSUPP] The file system does not support ACL retrieval.
This would be referring to the destination filesystem.
Looking through the md(4) source for references to EOPNOTSUPP, we do
find some references:
$ egrep -n -r EOPNOTSUPP|ENOTSUP /usr/src/sys/dev/md
/usr/src/sys/dev/md/md.c:423: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:475: error = EOPNOTSUPP;
/usr/src/sys/dev/md/md.c:523: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:601: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:731: error = EOPNOTSUPP;
Line 423 is within mdstart_malloc(), and it returns EOPNOTSUPP on any
BIO operation other than READ/WRITE/DELETE. Line 475 is a continuation
of that.
Line 508 is within mdstart_vnode(), behaving effectively the same as
line 423. Line 601 is within mdstart_swap(), behaving effectively the
same as line 423.
Line 731 is within md_kthread(), and indicates only BIO operation
BIO_GETATTR is supported. This would not be an ACL attribute thing,
but rather getting attributes of the backing device itself. The code
hints at that:
722 if (bp-bio_cmd == BIO_GETATTR) {
723 if ((sc-fwsectors sc-fwheads
724 (g_handleattr_int(bp, GEOM::fwsectors,
725 sc-fwsectors) ||
726 g_handleattr_int(bp, GEOM::fwheads,
727 sc-fwheads))) ||
728 g_handleattr_int(bp, GEOM::candelete, 1))
729 error = -1;
730 else
731 error = EOPNOTSUPP;
732 } else {
Thanks for the investigation! So this seems to be a bug in md? That's
too bad, I was enjoying using it to make my tinderbox builds faster.
Sorry, I should have been more clear -- my investigation wasn't to
determine if the issue you're reporting was a bug or not, but more along
the lines of hmm, where is userland getting EOPNOTSUPP from in the
kernel in this situation? It could be that some piece hasn't been
implemented somewhere yet (more an incomplete than a bug :-) ).
I tend to trace source the way I did above in hopes that someone (kernel
dev, etc.) will chime in and go Oh, yes, THAT... let me tell you about
that! It's also for educational purposes; I figure sharing the innards
along with some simple descriptions might help people feel more
comfortable (vs. thinking everything is a black box; don't let the magic
smoke out!). Sometimes digging through the code helps.
This leaves me with some ideas; just tossing them out here...
1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)? Try using mdconfig -t malloc -o reserve
instead, temporarily anyway.
Seems to be the same.
I'm not too surprised, but at least that rules out swap vs.
non-block-device stuff being somehow responsible.
I'm not a user of ACLs myself, but Robert Watson might know what's up
with this, or where to go looking. I've CC'd him here.
2. Are you absolutely 100% sure the kernel you're using was built
with options UFS_ACL defined in it? Doing a strings -a
/boot/kernel/kernel | grep UFS_ACL should suffice.
Yep, it does:
% strings -a /boot/kernel/kernel | grep UFS_ACL
options UFS_ACL
(My kernel config is just include GENERIC then a bunch of nooptions
for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)
Cool, good to rule out the obvious. Thanks.
The only other thing I can think of off the top of my head would be to
ktrace -t+ -i the cp -p, then provide output of kdump -s -t+ after.
I wouldn't say go about this quite yet (it may not even help determine
what's going on); maybe wait for Robert to take a look first.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-current@freebsd.org mailing list
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
On Sun, Mar 06, 2011 at 08:23:42AM -0800, Jeremy Chadwick wrote:
On Sun, Mar 06, 2011 at 11:06:09AM -0500, Steve Wills wrote:
On 03/06/11 10:37, Jeremy Chadwick wrote:
At first glance it looks like acl_set_fd_np(3) isn't working on an
md-backed filesystem; specifically, it's returning EOPNOTSUPP. You
should be able to reproduce the problem by doing a setfacl on something
in /tmp/foobar.
Looking through src/bin/cp/utils.c, this is the code:
420 if (acl_set_fd_np(dest_fd, acl, acl_type) 0) {
421 warn(failed to set acl entries for %s, to.p_path);
422 acl_free(acl);
423 return (1);
424 }
EOPNOTSUPP for acl_set_fd_np(3) is defined as:
[EOPNOTSUPP] The file system does not support ACL retrieval.
This would be referring to the destination filesystem.
Looking through the md(4) source for references to EOPNOTSUPP, we do
find some references:
$ egrep -n -r EOPNOTSUPP|ENOTSUP /usr/src/sys/dev/md
/usr/src/sys/dev/md/md.c:423: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:475: error = EOPNOTSUPP;
/usr/src/sys/dev/md/md.c:523: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:601: return (EOPNOTSUPP);
/usr/src/sys/dev/md/md.c:731: error =
EOPNOTSUPP;
Line 423 is within mdstart_malloc(), and it returns EOPNOTSUPP on any
BIO operation other than READ/WRITE/DELETE. Line 475 is a continuation
of that.
Line 508 is within mdstart_vnode(), behaving effectively the same as
line 423. Line 601 is within mdstart_swap(), behaving effectively the
same as line 423.
Line 731 is within md_kthread(), and indicates only BIO operation
BIO_GETATTR is supported. This would not be an ACL attribute thing,
but rather getting attributes of the backing device itself. The code
hints at that:
722 if (bp-bio_cmd == BIO_GETATTR) {
723 if ((sc-fwsectors sc-fwheads
724 (g_handleattr_int(bp, GEOM::fwsectors,
725 sc-fwsectors) ||
726 g_handleattr_int(bp, GEOM::fwheads,
727 sc-fwheads))) ||
728 g_handleattr_int(bp, GEOM::candelete,
1))
729 error = -1;
730 else
731 error = EOPNOTSUPP;
732 } else {
Thanks for the investigation! So this seems to be a bug in md? That's
too bad, I was enjoying using it to make my tinderbox builds faster.
Sorry, I should have been more clear -- my investigation wasn't to
determine if the issue you're reporting was a bug or not, but more along
the lines of hmm, where is userland getting EOPNOTSUPP from in the
kernel in this situation? It could be that some piece hasn't been
implemented somewhere yet (more an incomplete than a bug :-) ).
I tend to trace source the way I did above in hopes that someone (kernel
dev, etc.) will chime in and go Oh, yes, THAT... let me tell you about
that! It's also for educational purposes; I figure sharing the innards
along with some simple descriptions might help people feel more
comfortable (vs. thinking everything is a black box; don't let the magic
smoke out!). Sometimes digging through the code helps.
This leaves me with some ideas; just tossing them out here...
1. Maybe/somehow this is caused by swap being used as the backing
type/store for md(4)? Try using mdconfig -t malloc -o reserve
instead, temporarily anyway.
Seems to be the same.
I'm not too surprised, but at least that rules out swap vs.
non-block-device stuff being somehow responsible.
I'm not a user of ACLs myself, but Robert Watson might know what's up
with this, or where to go looking. I've CC'd him here.
2. Are you absolutely 100% sure the kernel you're using was built
with options UFS_ACL defined in it? Doing a strings -a
/boot/kernel/kernel | grep UFS_ACL should suffice.
Yep, it does:
% strings -a /boot/kernel/kernel | grep UFS_ACL
options UFS_ACL
(My kernel config is just include GENERIC then a bunch of nooptions
for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)
Cool, good to rule out the obvious. Thanks.
The only other thing I can think of off the top of my head would be to
ktrace -t+ -i the cp -p, then provide output of kdump -s -t+ after.
I wouldn't say go about this quite yet (it may not even help determine
what's going on); maybe wait for Robert to take a look first.
It would help if I actually added Robert to the CC list, wouldn't it?
:-)
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
|
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 15:43: On 03/06/11 08:35, Steve Wills wrote: On 03/06/11 04:22, Edward Tomasz NapieraBa wrote: Wiadomo[ napisana przez Steve Wills w dniu 2011-03-06, o godz. 05:11: [..] Thanks for your work on this, I'm very happy to have ZFS v28. I just updated my -CURRENT system from a snapshot from about a month ago to code from today. I have 3 pools and one of them is for ports tinderbox. I only upgraded that pool. When I try to build something using tinderbox, I get this error: cp: failed to set acl entries for /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/buildscript: Operation not supported What does mount show? /dev/md4 12186190 332724 11853466 3% /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD Sorry, I forgot about the mdmfs hacks I had in my local tinderd. Without them, it works fine. So the problem seems to be in mfs rather than zfs. I should have said mdmfs, but all that's doing is running mdconfig and newfs for me. I've reproduced the issue without mdmfs: % mdconfig -a -t swap -s 12G -u 4 % newfs -m 0 -o time /dev/md4 [...] % mount /dev/md4 /tmp/foobar % cp -p /usr/local/tinderbox/scripts/lib/buildscript /tmp/foobar cp: failed to set acl entries for /tmp/foobar/buildscript: Operation not supported Without -p it works fine. FWIW: % getfacl /usr/local/tinderbox/scripts/lib/buildscript # file: /usr/local/tinderbox/scripts/lib/buildscript # owner: root # group: wheel owner@:--:--:deny owner@:rwxp---A-W-Co-:--:allow group@:-w-p--:--:deny group@:r-x---:--:allow everyone@:-w-p---A-W-Co-:--:deny everyone@:r-x---a-R-c--s:--:allow Any suggestions on where the problem could be? The above looks like old-style, canonical six trivial ACL. Now, cp(1) shouldn't even try to copy the ACL in this case, since there is nothing to copy. So, for some reason, something failed between cp(1), acl_is_trivial_np(3) and the kernel. What does ls -al /usr/local/tinderbox/scripts/lib/buildscript show? -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/11 12:49, Edward Tomasz Napierała wrote: The above looks like old-style, canonical six trivial ACL. Now, cp(1) shouldn't even try to copy the ACL in this case, since there is nothing to copy. So, for some reason, something failed between cp(1), acl_is_trivial_np(3) and the kernel. What does ls -al /usr/local/tinderbox/scripts/lib/buildscript show? It looks like: - -rwxr-xr-x+ 1 root wheel 12547 Feb 1 21:21 /usr/local/tinderbox/scripts/lib/buildscript Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNc9IMAAoJEPXPYrMgexuhMmQH/jU7Zsay7fDmYP4UY60P63TH Zbq3jyitlhgh3BNyibbbJ3O0OsEUWEJ+xO5jz04g32Kvv/NFWqQD9tPygkABeBb2 v50K/uOS8VskcMoJaxzkOIDz2Y/0PNKHo+/Cft7/hMbW1W5h7ebe7peKn7FA/F6R MzFY6RMe6sY4x00gxpo/f3DQAB5VR6MqQl5SbDMUE8dP7ut5gUe9f+QvJPc2OgMA thCLqxEfjKohWtpmuctr1c8Ap3UKvAAzwUVT6qs+CNidaxb3qzXLDyA9Z614GVAy 1WQxTsEtfiByMm6N1qUqIkNZNFmFSO0cEuRyK8Z4FJ0ZA5X4smk8gicATp/wAPQ= =Y/S+ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)
Wiadomość napisana przez Steve Wills w dniu 2011-03-06, o godz. 19:27: On 03/06/11 12:49, Edward Tomasz Napierała wrote: The above looks like old-style, canonical six trivial ACL. Now, cp(1) shouldn't even try to copy the ACL in this case, since there is nothing to copy. So, for some reason, something failed between cp(1), acl_is_trivial_np(3) and the kernel. What does ls -al /usr/local/tinderbox/scripts/lib/buildscript show? It looks like: - -rwxr-xr-x+ 1 root wheel 12547 Feb 1 21:21 /usr/local/tinderbox/scripts/lib/buildscript r219272 introduced an error which made libc treat the canonical six ACLs as nontrivial. I backed it out; you need to rebuild libc. Sorry. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
