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"
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. 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!)
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
>
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
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 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 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 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 |
_
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: HEADS UP: ZFSv28 is in!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/11 04:22, Edward Tomasz Napierała 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. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNc42wAAoJEPXPYrMgexuhYiwH/0k+HYFiWHgDlpbEZL5xEYHS +ZlOZ19kW58A648iVbzuBgGWcQIEkylflJc23pigue+Qm5gvUR9PYZmr20hleCow 96pOxlQOyu1yJ/w90yJsfOTnVXfwdgEZWrHwiW+dDQp1YCGjnXqiocHT6gjukCNV HSm6hEMI9YD5y75tVZVep/en6VmSwywsLlHEL5T8M+x1bsUUkawCltNUcbYLfJWS NMuyG1ZudwscTj1bZHKyz+1bu5sToBj/w8aU7vASn5wvIjnKhMo/DDiCICyykbQ1 7Qa3i+BfG7ugvq6WxV7OiiCTYzx8f8R2D9QOtz6wmAPLkQbItRfdX7i0lxG+nig= =h6fT -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: HEADS UP: ZFSv28 is in!
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? -- 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: HEADS UP: ZFSv28 is in!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Pawel, On 02/27/11 15:29, Pawel Jakub Dawidek wrote: > Hi. > > I just committed ZFSv28 to HEAD. > > New major features: > > - Data deduplication. > - Triple parity RAIDZ (RAIDZ3). > - zfs diff. > - zpool split. > - Snapshot holds. > - zpool import -F. Allows to rewind corrupted pool to earlier > transaction group. > - Possibility to import pool in read-only mode. > > PS. If you like my work, you help me to promote yomoli.com:) > > http://yomoli.com > http://www.facebook.com/pages/Yomolicom/178311095544155 > 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 If I delete the /usr/local/tinderbox/9-CURRENT-amd64-FreeBSD/ directory then try to build, I get no errors. Could this be a bug in tinderbox or something else? It was working fine before the update as far as I know. Thanks, Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJNcwmPAAoJEPXPYrMgexuhoXUH/jelhA/5sebWUjp2mEQ3GWYj GBIxM0H3v4kzRQ3CxQ3ACC/piXcDtF+j33KJl1032DgrijaWLs9kj1vdQd1ye5xc A9qN4Ek++/w3+JoLWkyyzIyg2/glIy/VaVdzXClEjR5GC02M3QG62OwVYyKEHicC 7FzeFHVRw29Rs6Rael3vkGospXfo7ha8uhc8Dv+kqLnmeBEaTYllpjtyzd9DbM38 01DhMc6Yg0EWbOF4h1wL6dwQDGDc0aBlLV8IWft90wVtewZWAhVGhrCBWLAflPWn X6lSg74PLryANaV7Vmk9MvR+9McCwCFstrVVCvAnAwlUYJ5Umo8h0uRWY5bt9mA= =EMs5 -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: HEADS UP: ZFSv28 is in!
28.02.2011 15:24, lhmwzy wrote: Tks for PJD's work for zfs. Would V28 is the last version of zfs because oracle don't open the zfs code after V28? 1. Oracle opens the code, but only after some time. AFAIR they do open the code after the major releases. 2. All head developers have quit Oracle. They say technology is complete an should go on by itself. 3. With current work going on in Illumos aren't we sharing the role of 'core' for ZFS development? -- Sphinx of black quartz judge my vow. ___ 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: HEADS UP: ZFSv28 is in!
Alexander Leidinger wrote: > Quoting Fabian Keil (from Thu, 3 Mar > 2011 13:01:30 +0100): > > > Alexander Leidinger wrote: > > > >> On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil > >> wrote: > >> > >> > Pawel Jakub Dawidek wrote: > >> > > >> > > I just committed ZFSv28 to HEAD. > >> > > >> > I updated the system without removing the tuning for ZFSv15 > >> > first, and somehow this completely messed up the performance. > >> > Booting the system took more than ten minutes and even once > >> > it was up it was next to unresponsive. > >> > > >> > I'm not sure which sysctl was to blame, but after removing > >> > all but vfs.zfs.arc_max="800M" and rebooting, the problem > >> > was gone. > >> > >> When you add the tuning back, does it take minutes again to boot? If > >> not, I assume it was cleaning up some leftovers the old version was not > >> able to cleanup. > > > > I haven't tried that yet, but as I didn't upgrade the system's > > storage pool I don't think ZFS is supposed to do any such clean-ups. > > AFAIK the new code knows how to remove some superfluous parts in your > pool (no matter at which version the pool is), which the old code just > skipped over. Such leftovers may not be in all pools, they show up > just in some use cases. For this reason I asked to verify by adding > the tuning back to this system (if possible). I don't have an exact list of sysctls I used earlier, but after commenting in all the zfs sysctls in loader.conf (some of which must have been commented out for quite some time) the problem was back. I interrupted the boot process after 14 minutes at which point the ezjail rc script was running for several minutes already, but still busy with the first jail. Usually this takes only a few seconds. The sysctls used were: #vfs.zfs.txg.timeout=5 Seems to be the default now. # vfs.zfs.zil_disable=1 No longer supported. # vfs.zfs.prefetch_disable=0 The default seems to be 1. # vfs.zfs.write_limit_override=15 Clearly the value makes no sense, so this may not have been active at the time of the update. I had a back-ported patch to add the sysctl, so at least in theory it should have caused problems with v15, too, unless there was a sanity check to ignore obviously incorrect values. The auto-tuned write-limit values are: vfs.zfs.write_limit_max: 258863616 vfs.zfs.write_limit_min: 33554432 # vfs.zfs.vdev.max_pending=15 The auto-tuned value is 10. vfs.zfs.arc_max="800M" # vfs.zfs.arc_min="500M" # vfs.zfs.vdev.cache.size="5M" The auto-tuned value is 10485760 which seems close enough. # vfs.zfs.txg.synctime=1 This sysctl doesn't seem to exist (anymore). #vfs.zfs.cache_flush_disable=1 The default is 0. # vfs.zfs.txg.write_limit_override=134217728 Doesn't seem to exist (anymore) either. #vfs.zfs.vdev.max_pending=2 #vfs.zfs.vdev.min_pending=1 The auto-tuned values are vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 10 > If it is not a production-like system which does not accept downtime, > this verification consumes less resources than sending out a developer > hunting for a problem which may not even exist. It wasn't my intention to send anyone hunting. Fabian signature.asc Description: PGP signature
Re: HEADS UP: ZFSv28 is in!
On Thu, 3 Mar 2011, Fabian Keil wrote: When you add the tuning back, does it take minutes again to boot? If not, I assume it was cleaning up some leftovers the old version was not able to cleanup. I haven't tried that yet, but as I didn't upgrade the system's storage pool I don't think ZFS is supposed to do any such clean-ups. The new code likely does things like search for and reclaim leaked space. Older zfs versions had some some bugs which could result in failing to reclaim space after a large file is deleted. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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: HEADS UP: ZFSv28 is in!
Quoting Fabian Keil (from Thu, 3 Mar 2011 13:01:30 +0100): Alexander Leidinger wrote: On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil wrote: > Pawel Jakub Dawidek wrote: > > > I just committed ZFSv28 to HEAD. > > I updated the system without removing the tuning for ZFSv15 > first, and somehow this completely messed up the performance. > Booting the system took more than ten minutes and even once > it was up it was next to unresponsive. > > I'm not sure which sysctl was to blame, but after removing > all but vfs.zfs.arc_max="800M" and rebooting, the problem > was gone. When you add the tuning back, does it take minutes again to boot? If not, I assume it was cleaning up some leftovers the old version was not able to cleanup. I haven't tried that yet, but as I didn't upgrade the system's storage pool I don't think ZFS is supposed to do any such clean-ups. AFAIK the new code knows how to remove some superfluous parts in your pool (no matter at which version the pool is), which the old code just skipped over. Such leftovers may not be in all pools, they show up just in some use cases. For this reason I asked to verify by adding the tuning back to this system (if possible). If it is not a production-like system which does not accept downtime, this verification consumes less resources than sending out a developer hunting for a problem which may not even exist. Bye, Alexander. -- A short cut is the longest distance between two points. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: HEADS UP: ZFSv28 is in!
Alexander Leidinger wrote: > On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil > wrote: > > > Pawel Jakub Dawidek wrote: > > > > > I just committed ZFSv28 to HEAD. > > > > I updated the system without removing the tuning for ZFSv15 > > first, and somehow this completely messed up the performance. > > Booting the system took more than ten minutes and even once > > it was up it was next to unresponsive. > > > > I'm not sure which sysctl was to blame, but after removing > > all but vfs.zfs.arc_max="800M" and rebooting, the problem > > was gone. > > When you add the tuning back, does it take minutes again to boot? If > not, I assume it was cleaning up some leftovers the old version was not > able to cleanup. I haven't tried that yet, but as I didn't upgrade the system's storage pool I don't think ZFS is supposed to do any such clean-ups. I also don't see any similar issues when importing other v15 pools. Fabian signature.asc Description: PGP signature
Re: HEADS UP: ZFSv28 is in!
On Mon, Feb 28, 2011 at 08:34:08AM +0100, Martin Sugioarto wrote: > > PS. If you like my work, you help me to promote yomoli.com:) > > > > http://yomoli.com > > http://www.facebook.com/pages/Yomolicom/178311095544155 > > > > I would like, but you should at least tell me what it is (what will be > sold there). I don't like to advertise things I don't know or even > things that seem "evil" to me. > > I'll post your answer to a well-known German *BSD forum, if you want. Well, I didn't want to say too much about it here, as it isn't really related to FreeBSD. This is a startup I'm working on which is location-based chat, which allows users to communicate with their neighborhood. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpe1gJOLMeSe.pgp Description: PGP signature
Re: HEADS UP: ZFSv28 is in!
On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil wrote: > Pawel Jakub Dawidek wrote: > > > I just committed ZFSv28 to HEAD. > > I updated the system without removing the tuning for ZFSv15 > first, and somehow this completely messed up the performance. > Booting the system took more than ten minutes and even once > it was up it was next to unresponsive. > > I'm not sure which sysctl was to blame, but after removing > all but vfs.zfs.arc_max="800M" and rebooting, the problem > was gone. When you add the tuning back, does it take minutes again to boot? If not, I assume it was cleaning up some leftovers the old version was not able to cleanup. Bye, Alexander. ___ 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: HEADS UP: ZFSv28 is in!
Pawel Jakub Dawidek wrote: > I just committed ZFSv28 to HEAD. I updated the system without removing the tuning for ZFSv15 first, and somehow this completely messed up the performance. Booting the system took more than ten minutes and even once it was up it was next to unresponsive. I'm not sure which sysctl was to blame, but after removing all but vfs.zfs.arc_max="800M" and rebooting, the problem was gone. I haven't seen this issue with earlier ZFS updates, so maybe this would be worth mentioning in UPDATING? Anyway, the things I tested so far (zfs/zpool upgrade, delegation, send, receive, snapshot) worked fine. Thanks a lot. Fabian signature.asc Description: PGP signature
Re: HEADS UP: ZFSv28 is in!
Tks for PJD's work for zfs. Would V28 is the last version of zfs because oracle don't open the zfs code after V28? 2011/2/28 Pawel Jakub Dawidek : > Hi. > > I just committed ZFSv28 to HEAD. > > New major features: > > - Data deduplication. > - Triple parity RAIDZ (RAIDZ3). > - zfs diff. > - zpool split. > - Snapshot holds. > - zpool import -F. Allows to rewind corrupted pool to earlier > transaction group. > - Possibility to import pool in read-only mode. > > PS. If you like my work, you help me to promote yomoli.com:) > > http://yomoli.com > http://www.facebook.com/pages/Yomolicom/178311095544155 > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com > ___ 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: HEADS UP: ZFSv28 is in!
On 28 February 2011 08:47, Pawel Jakub Dawidek wrote: > On Sun, Feb 27, 2011 at 04:03:01PM -0700, Shawn Webb wrote: >> I'm so excited for your work. Thanks so much for bringing zpool v28 to >> FreeBSD. Will v28 come to 8-stable? > > Yes, hopefully in 1-2 month(s). > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com > ive never managed to be able to boot off my 4k aligned pool (ashift=12) on stable, does the import to head provide all the patches for this or is it a case of using the latest zfs v28 patch set for stable? I have no dying need for v28 yet, it just want to be able to boot onto the 4k drive and tidy things up. ___ 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: HEADS UP: ZFSv28 is in!
On Sun, Feb 27, 2011 at 09:29:57PM +0100, Pawel Jakub Dawidek wrote: > I just committed ZFSv28 to HEAD. Thank you so much for this effort! I look forward to trying this once it's MFC'd to RELENG_8 in the upcoming future. -- | 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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ZFSv28 is in!
On Mon, Feb 28, 2011 at 10:37:25AM +, krad wrote: > On 28 February 2011 08:47, Pawel Jakub Dawidek wrote: > > On Sun, Feb 27, 2011 at 04:03:01PM -0700, Shawn Webb wrote: > >> I'm so excited for your work. Thanks so much for bringing zpool v28 to > >> FreeBSD. Will v28 come to 8-stable? > > > > Yes, hopefully in 1-2 month(s). > > > > -- > > Pawel Jakub Dawidek http://www.wheelsystems.com > > FreeBSD committer http://www.FreeBSD.org > > Am I Evil? Yes, I Am! http://yomoli.com > > > > ive never managed to be able to boot off my 4k aligned pool > (ashift=12) on stable, does the import to head provide all the patches > for this or is it a case of using the latest zfs v28 patch set for > stable? I have no dying need for v28 yet, it just want to be able to > boot onto the 4k drive and tidy things up. Support for this is included in what I committed to HEAD. Even HEAD couldn't boot off of pools with ashift != 9 until now. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpoBcg2ska7K.pgp Description: PGP signature
Re: HEADS UP: ZFSv28 is in!
On Sun, Feb 27, 2011 at 04:03:01PM -0700, Shawn Webb wrote: > I'm so excited for your work. Thanks so much for bringing zpool v28 to > FreeBSD. Will v28 come to 8-stable? Yes, hopefully in 1-2 month(s). -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgp1UOEA9rzOR.pgp Description: PGP signature
Re: HEADS UP: ZFSv28 is in!
Am Sun, 27 Feb 2011 21:29:57 +0100 schrieb Pawel Jakub Dawidek : > Hi. > > I just committed ZFSv28 to HEAD. > > New major features: > > - Data deduplication. > - Triple parity RAIDZ (RAIDZ3). > - zfs diff. > - zpool split. > - Snapshot holds. > - zpool import -F. Allows to rewind corrupted pool to earlier > transaction group. > - Possibility to import pool in read-only mode. Thank you Pawel! > PS. If you like my work, you help me to promote yomoli.com:) > > http://yomoli.com > http://www.facebook.com/pages/Yomolicom/178311095544155 > I would like, but you should at least tell me what it is (what will be sold there). I don't like to advertise things I don't know or even things that seem "evil" to me. I'll post your answer to a well-known German *BSD forum, if you want. -- Martin Sugioarto signature.asc Description: PGP signature
RE: HEADS UP: ZFSv28 is in!
Yay! Thanks for all of your work on ZFS. I was just about to inquire about when this was going to happen. I've been having great success with v28 in the Dec 12 2010 version, other than my minor complaints about imports and speed. Concerning speed, I've been running further speed tests this weekend with FreeBSD trying to isolate what effect NFS has on my tests. Earlier I found a Solaris 11 box being faster than a FreeBSD 9 box for the same hardware. I notice giant-lock logic in the NFS server code, and while it shouldn't be in play for a MP safe fs like ZFS, I'm not sure. I have a few NFS custom tests, including forcing async in the code even when VMWare opens it as O_SYNC. Judging by the Solaris speed difference, I think they must be silently doing something similar to get the speed they do on ZFS with a ZIL enabled. I also need to look into how the Intel X520 card is setup in Solaris compared to FreeBSD, as it may be my speed limiter. This will make further testing much easier now that I no longer need to juggle patches. Thanks again. -Original Message- From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org] On Behalf Of Pawel Jakub Dawidek Sent: Sunday, February 27, 2011 4:30 PM To: freebsd...@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: HEADS UP: ZFSv28 is in! Hi. I just committed ZFSv28 to HEAD. New major features: - Data deduplication. - Triple parity RAIDZ (RAIDZ3). - zfs diff. - zpool split. - Snapshot holds. - zpool import -F. Allows to rewind corrupted pool to earlier transaction group. - Possibility to import pool in read-only mode. PS. If you like my work, you help me to promote yomoli.com:) http://yomoli.com http://www.facebook.com/pages/Yomolicom/178311095544155 -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com ___ 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: HEADS UP: ZFSv28 is in!
I'm so excited for your work. Thanks so much for bringing zpool v28 to FreeBSD. Will v28 come to 8-stable? Thanks, Shawn On Feb 27, 2011 1:56 PM, "Pawel Jakub Dawidek" wrote: > Hi. > > I just committed ZFSv28 to HEAD. > > New major features: > > - Data deduplication. > - Triple parity RAIDZ (RAIDZ3). > - zfs diff. > - zpool split. > - Snapshot holds. > - zpool import -F. Allows to rewind corrupted pool to earlier > transaction group. > - Possibility to import pool in read-only mode. > > PS. If you like my work, you help me to promote yomoli.com:) > > http://yomoli.com > http://www.facebook.com/pages/Yomolicom/178311095544155 > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com ___ 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"
HEADS UP: ZFSv28 is in!
Hi. I just committed ZFSv28 to HEAD. New major features: - Data deduplication. - Triple parity RAIDZ (RAIDZ3). - zfs diff. - zpool split. - Snapshot holds. - zpool import -F. Allows to rewind corrupted pool to earlier transaction group. - Possibility to import pool in read-only mode. PS. If you like my work, you help me to promote yomoli.com:) http://yomoli.com http://www.facebook.com/pages/Yomolicom/178311095544155 -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpGTPfcT34QE.pgp Description: PGP signature
