Re: [zfs-discuss] installing OpenSolaris not easy-how does someone simply upgrade snv94 t

[Marc]

Hi,

uname -a 

SunOS ns1a 5.11 snv_94 sun4u sparc SUNW,Sun-Fire-280R

sol-nv-B94-sparc-dvd.iso

The upgrade I tried was called osol-0811-95.iso   but that would not allow to 
do anything.

# df
/  (/dev/dsk/c1t0d0s0 ):50209260 blocks  3689703 files
/devices   (/devices  ):   0 blocks0 files
/dev   (/dev  ):   0 blocks0 files
/system/contract   (ctfs  ):   0 blocks 2147483616 files
/proc  (proc  ):   0 blocks29954 files
/etc/mnttab(mnttab):   0 blocks0 files
/etc/svc/volatile  (swap  ): 6937968 blocks   280428 files
/system/object (objfs ):   0 blocks 2147483477 files
/etc/dfs/sharetab  (sharefs   ):   0 blocks 2147483646 files
/platform/sun4u-us3/lib/libc_psr.so.1(/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1):50209260
 blocks  3689703 files
/platform/sun4u-us3/lib/sparcv9/libc_psr.so.1(/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1):50209260
 blocks  3689703 files
/dev/fd(fd):   0 blocks0 files
/tmp   (swap  ): 6937968 blocks   280428 files
/var/run   (swap  ): 6937968 blocks   280428 files
#
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] GUI support for ZFS root?

[Lukas Oboril]

On Thu, Aug 14, 2008 at 6:00 PM, Rich Teer <[EMAIL PROTECTED]> wrote:

> On Thu, 14 Aug 2008, Ross wrote:
>
> > Huh?  Now I'm confused, I thought b95 was just the latest build of
> > OpenSolaris, I didn't realise that OpenSolaris 2008.05 was different, I
> > thought it was just an older, more stable build that was updated less
> > often.
>
> Welcome to the world of ret-conning.  What is officially referred to as
> OpenSolaris today was originally called Project Indiana (the OpenSolaris
> moniker being used for the whole project).  It's the result of a unilateral
> move by some Sun management that still leaves a bad taste in many people's
> mouths (mine included).
>
> > Is there anything else I'm missing out on by using snv_94 instead of
> > OpenSolaris 2008.05?
>
> I doubt it.  Unless you want a Solaris that's trying real hard to look
> like Linux, that is...
>
>
> Summary: Solaris Express Community Edition (SXCE) is like the OpenSolaris
> of old; OpenSolaris .xx is apparently Sun's intended future direction
> for Solaris.  Based on what I've heard, I've not tried the latter.  If I
> wanted Linux I'd use Linux.  But for the foreseeable future, I'm sticking
> to SXCE.
>

absolutely agree with you.


>
> --
> Rich Teer, SCSA, SCNA, SCSECA
>
> CEO,
> My Online Home Inventory
>
> URLs: http://www.rite-group.com/rich
>  http://www.linkedin.com/in/richteer
>  http://www.myonlinehomeinventory.com
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>



-- 
Lukas 'Luc' Oboril
IRC nickname: luc^ at freenode


When dealing with people, let us remember we are not dealing with creatures
of logic. We are dealing with creatures of emotions, creatures bristling
with prejudices and motivated by pride and vanity. Dale Carnegie
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] corrupt zfs stream? checksum mismatch

[Jonathan Wheeler]

Hi Richard,

Thanks for the detailed reply, and the work behind the scenes filing the CRs.
I've bookmarked both, and will keep a keen eye on them for status changes.

As Miles put it, I'll have to put these dumps into storage for possible future 
use.
I do dearly hope that I'll be able to recover most of that data in the future, 
but for the most important bits (documents/spreadsheets), I'll have to rebuild 
them by way of some rather intensive data entry based on hard copies, now.

Not fun.

I do have a working [zfs send dump!] backup from October, so it's not a total 
loss of my livelihood, but it'll be a life lesson alright.

With CR 6736794, I wonder if some extra notes could be added around the 
checksumming side of the code?
The wording that has been used doesn't quite match my scenario, but I certainly 
agree with what  requested functionality has been requested there.

I have a 50GB zfs send dump and zfs receive is failing (and rolling back) 
around the 20GB mark.
While the exact cause and nature of my issue remains unknown, I very much 
expect that the vast majority of my zfs send dump is in fact in tact, including 
data beyond that 20GB checksum error point. I.E there is a problem around the 
20GB mark, but I expect that the remaining 30GB contains "good" data, or in 
very least, *mostly* good data.

The CR appears to be only requesting that zfs receive stop at the 20GB mark, 
but {new feature} allows the failed restore attempt to be mountable, in a 
unknown/known bad state.

I'd much prefer that zfs receive continue on error too, thus giving it the full 
50GB to process and attempt to repair, rather than only the data up until the 
point that it encountered it's first problem.

Without knowing much about the actual on disk format,metadata and structures I 
can't be sure, but the fs is going to have a much better chance at recovering 
when there is more data available across the entire length of the fs, right? I 
know from my linux days that the ext2/3 superblocks were distributed across the 
full disk, so the more of the disk that it can attempt to read, the better the 
chance that it'll find more correct metadata to use in an attempt a repair of 
the FS.

And of course the second benefit of reading more of the data stream, past an 
error is that more user data will at least have a chance of being recovered. If 
it stops half way, it has _no_ chance of recovering that data, so I favor my 
odds of letting it go on to at least try :)

Or is that an entirely new CR itself?

Jonathan
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] GUI support for ZFS root?

[Wilkinson, Alex]

0n Thu, Aug 14, 2008 at 09:00:12AM -0700, Rich Teer wrote: 

>Summary: Solaris Express Community Edition (SXCE) is like the OpenSolaris
>of old; OpenSolaris .xx is apparently Sun's intended future direction
>for Solaris.  Based on what I've heard, I've not tried the latter.  If I
>wanted Linux I'd use Linux.  But for the foreseeable future, I'm sticking
>to SXCE.

Does that mean SXCE is going to disapear and be replaced by .xx ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] FW: Supermicro AOC-SAT2-MV8 hang when drive removed

[Ross]

Haven't a clue, but I've just gotten around to installing windows on this box 
to test and I can confirm that hot plug works just fine in windows.

Drives appear and dissappear in device manager the second I unplug the 
hardware.  Any drive, either controller.  So far I've done a couple of dozen 
removals, pulling individual drives, or as many as half a dozen at once.  I've 
even gone as far as to immediately pull a drive I only just connected.  Windows 
has no problems at all.

Unfortunately for me, Windows doesn't support ZFS...  right now it's looking a 
whole load more stable.

Ross


> 
> I don't have any extra cards lying
> around and can't really take my server down, so
> my immediate question would be:Is there any sort
> of PCI bridge chip on the card?  I know in my
> experience I've seen all sorts of headaches with
> less than stellar bridge chips.  Specifically
> some of the IBM bridge chips.
> Food for
> thought.--Tim
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] FW: Supermicro AOC-SAT2-MV8 hang when drive removed

[Tim]

You could always try FreeBSD :)

--Tim

On Fri, Aug 15, 2008 at 9:44 AM, Ross <[EMAIL PROTECTED]> wrote:

> Haven't a clue, but I've just gotten around to installing windows on this
> box to test and I can confirm that hot plug works just fine in windows.
>
> Drives appear and dissappear in device manager the second I unplug the
> hardware.  Any drive, either controller.  So far I've done a couple of dozen
> removals, pulling individual drives, or as many as half a dozen at once.
>  I've even gone as far as to immediately pull a drive I only just connected.
>  Windows has no problems at all.
>
> Unfortunately for me, Windows doesn't support ZFS...  right now it's
> looking a whole load more stable.
>
> Ross
>
>
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] FW: Supermicro AOC-SAT2-MV8 hang when drive removed

[Ross Smith]

Oh god no, I'm already learning three new operating systems, now is not a good 
time to add a fourth.
 
Ross<-- Windows admin now working with Ubuntu, OpenSolaris and ESX



Date: Fri, 15 Aug 2008 10:07:31 -0500From: [EMAIL PROTECTED]: [EMAIL 
PROTECTED]: Re: [zfs-discuss] FW: Supermicro AOC-SAT2-MV8 hang when drive 
removedCC: zfs-discuss@opensolaris.org
You could always try FreeBSD :)--Tim
On Fri, Aug 15, 2008 at 9:44 AM, Ross <[EMAIL PROTECTED]> wrote:
Haven't a clue, but I've just gotten around to installing windows on this box 
to test and I can confirm that hot plug works just fine in windows.Drives 
appear and dissappear in device manager the second I unplug the hardware.  Any 
drive, either controller.  So far I've done a couple of dozen removals, pulling 
individual drives, or as many as half a dozen at once.  I've even gone as far 
as to immediately pull a drive I only just connected.  Windows has no problems 
at all.Unfortunately for me, Windows doesn't support ZFS...  right now it's 
looking a whole load more stable.Ross
_
Win a voice over part with Kung Fu Panda & Live Search   and   100’s of Kung Fu 
Panda prizes to win with Live Search
http://clk.atdmt.com/UKM/go/107571439/direct/01/___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] GUI support for ZFS root?

[Ivan Wang]

> 0n Thu, Aug 14, 2008 at 09:00:12AM -0700, Rich
>  Teer wrote: 
> >Summary: Solaris Express Community Edition
>  (SXCE) is like the OpenSolaris
> >of old; OpenSolaris .xx is apparently Sun's
>  intended future direction
> >for Solaris.  Based on what I've heard, I've not
>  tried the latter.  If I
> >wanted Linux I'd use Linux.  But for the
>  foreseeable future, I'm sticking
>>to SXCE.
> es that mean SXCE is going to disapear and be
> replaced by .xx ?

This, at least to my knowledge, has never been *officially* answered, but 
consensus is yes (means it happens eventually, without specific date)

Time to practice linux crossdressing. :)

Ivan.


> 
>  -aW
> IMPORTANT: This email remains the property of the
> Australian Defence Organisation and is subject to the
> jurisdiction of section 70 of the CRIMES ACT 1914.
> If you have received this email in error, you are
> requested to contact the sender and delete the
>  email.
> 
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discu
> ss
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Jumpstart + ZFS boot: profile?

[Vincent Fox]

I'm not sure why you want to separate out all these filesystems on a root disk 
these days?  The reason I recall needing to do it over a decade ago, was 
because disks were so small and perhaps you couldn't FIT /opt onto the same 
disk with /usr.  So you needed to be able to say /usr is on this disk and /opt 
is over here on another one.

Perhaps it would be good if you explained the need for all these filesystems?

If you have apps that need a lot of space, they can have their own filesystems 
created after the OS is installed.  Like your /joker for instance, just do a 
zfs create for that after the OS install.

This is my profile:

#
#clusterThis tells what cluster of packages to install.
#   SUNWCXall is Entire Solaris Software Group Plus OEM 
Support.
#   SUNWCall is Entire Solaris Software Group.
#   SUNWCprog is Developer Solaris Software Group.
#   SUNWCuser is End User Solaris Software Group.
#   SUNWCreq is Core System Support Software Group.
#   SUNWCrnet is Reduced Network Support Software Group.
install_typeinitial_install
poolrpool auto auto auto mirror c1t0d0s0 c1t1d0s0
bootenv installbe bename zfsroot dataset /var
system_type standalone
cluster SUNWCXall

For applications which need a little space that is tightly managed to not 
impact other applications running on the same system, like 
scratch/tmp/lock-files which might go nuts, I just give them a piece of the 
TMPFS filesystem and set a limit on it's size in /etc/vfstab:

swap-   /var/imap-proc  tmpfs   -   yes size=512m
swap-   /var/imap-socket  tmpfs   -   yes   size=512m
swap-   /var/imap-log   tmpfs   -   yes size=512m
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] FW: Supermicro AOC-SAT2-MV8 hang when drive removed

[Florin Iucha]

On Fri, Aug 15, 2008 at 10:07:31AM -0500, Tim wrote:
> You could always try FreeBSD :)
>
> > Unfortunately for me, Windows doesn't support ZFS...  right now it's
> > looking a whole load more stable.

Nope: FreeBSD doesn't have proper power management either.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


pgpOZ7C2tjYVb.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] zpool detach from degraded mirror : why "only applicable to mirror ..." ?

[Nils Goroll]

Hi,

I thought that this question must have been answered already, but I have
not found any explanations. I'm sorry in advance if this is redundant, but:

Why exactly doesn't ZFS let me detach a device from a degraded mirror?

haggis:~# zpool  status
  pool: rmirror
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-9P
 scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rmirror  DEGRADED 0 0 0
  c15t0d0s0  ONLINE   0 0 0
  c16t0d0s0  DEGRADED 0 0 0  too many errors

errors: No known data errors

haggis:~# zpool detach rmirror c16t0d0s0
cannot detach c16t0d0s0: only applicable to mirror and replacing vdevs

Background: My system was crashing twice during a zpool scrub,
so I thought I should avoid a third scrubbing attemt and rather detach
and re-attach the mirror to achieve a full re-sync.

this is snv_93

Ref:

http://docs.sun.com/app/docs/doc/817-2271/gcfhe?l=en&a=view&q=%22only+applicable+to+mirror+and+replacing+vdevs%22
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool detach from degraded mirror : why "only applicable to mirror ..." ?

[Mattias Pantzare]

2008/8/15 Nils Goroll <[EMAIL PROTECTED]>:
> Hi,
>
> I thought that this question must have been answered already, but I have
> not found any explanations. I'm sorry in advance if this is redundant, but:
>
> Why exactly doesn't ZFS let me detach a device from a degraded mirror?
>
> haggis:~# zpool  status
>  pool: rmirror
>  state: DEGRADED
> status: One or more devices has experienced an unrecoverable error.  An
>attempt was made to correct the error.  Applications are unaffected.
> action: Determine if the device needs to be replaced, and clear the errors
>using 'zpool clear' or replace the device with 'zpool replace'.
>   see: http://www.sun.com/msg/ZFS-8000-9P
>  scrub: none requested
> config:
>
>NAME STATE READ WRITE CKSUM
>rmirror  DEGRADED 0 0 0
>  c15t0d0s0  ONLINE   0 0 0
>  c16t0d0s0  DEGRADED 0 0 0  too many errors
>

That is not a mirror. This is an example of a mirror (3-way):

NAME STATE READ WRITE CKSUM
rpool ONLINE   0 0 0
  mirror  ONLINE   0 0 0
c1d0s0ONLINE   0 0 1
c2d0s0ONLINE   0 0 1
c4t0d0s0  ONLINE   0 0 0
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool detach from degraded mirror : why "only applicable to mirror ..." ?

[Eric Schrock]

The fact that it's DEGRADED and not FAULTED indicates that it thinks the
DTL (dirty time logs) for the two sides of the mirrors overlap in some
way, so detaching it would result in loss of data.  In the process of
doing this, it seems the error message got lost, and you ended up with
something completely non-sensical.  If you do a 'zpool scrub', does it
complete without any errors?

- Eric

On Fri, Aug 15, 2008 at 01:48:48PM -0700, Nils Goroll wrote:
> Hi,
> 
> I thought that this question must have been answered already, but I have
> not found any explanations. I'm sorry in advance if this is redundant, but:
> 
> Why exactly doesn't ZFS let me detach a device from a degraded mirror?
> 
> haggis:~# zpool  status
>   pool: rmirror
>  state: DEGRADED
> status: One or more devices has experienced an unrecoverable error.  An
>   attempt was made to correct the error.  Applications are unaffected.
> action: Determine if the device needs to be replaced, and clear the errors
>   using 'zpool clear' or replace the device with 'zpool replace'.
>see: http://www.sun.com/msg/ZFS-8000-9P
>  scrub: none requested
> config:
> 
>   NAME STATE READ WRITE CKSUM
>   rmirror  DEGRADED 0 0 0
>   c15t0d0s0  ONLINE   0 0 0
>   c16t0d0s0  DEGRADED 0 0 0  too many errors
> 
> errors: No known data errors
> 
> haggis:~# zpool detach rmirror c16t0d0s0
> cannot detach c16t0d0s0: only applicable to mirror and replacing vdevs
> 
> Background: My system was crashing twice during a zpool scrub,
> so I thought I should avoid a third scrubbing attemt and rather detach
> and re-attach the mirror to achieve a full re-sync.
> 
> this is snv_93
> 
> Ref:
> 
> http://docs.sun.com/app/docs/doc/817-2271/gcfhe?l=en&a=view&q=%22only+applicable+to+mirror+and+replacing+vdevs%22
>  
>  
> This message posted from opensolaris.org
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

--
Eric Schrock, Fishworkshttp://blogs.sun.com/eschrock
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool detach from degraded mirror : why "only applicable to mirror ..." ?

[Eric Schrock]

On Fri, Aug 15, 2008 at 02:14:02PM -0700, Eric Schrock wrote:
> The fact that it's DEGRADED and not FAULTED indicates that it thinks the
> DTL (dirty time logs) for the two sides of the mirrors overlap in some
> way, so detaching it would result in loss of data.  In the process of
> doing this, it seems the error message got lost, and you ended up with
> something completely non-sensical.  If you do a 'zpool scrub', does it
> complete without any errors?

Ooops, points to Mattias to paying more attention than I was :-)

- Eric

--
Eric Schrock, Fishworkshttp://blogs.sun.com/eschrock
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool detach from degraded mirror : why "only applicable to mirror ..

[Nils Goroll]

Matthias,

that does not answer my question.

The question is: Why can't I decide that I consciously want to destroy the (two 
way)
mirror (and, yes, do away with any redundancy).

Nils
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool detach from degraded mirror : why "only applicable to mirror ..

[Ronald Kuehn]

On Saturday, August 16, 2008 at 00:05:17 CEST, Nils Goroll wrote:
> Matthias,
> 
> that does not answer my question.
> 
> The question is: Why can't I decide that I consciously want to destroy the 
> (two way)
> mirror (and, yes, do away with any redundancy).
> 

Hi,

this pool does not have any redundancy because it is not a mirror.
Hence you can't detach anything from it. The pool is named "rmirror".
That does not make it a mirror.

>   NAME STATE READ WRITE CKSUM
>   rmirror  DEGRADED 0 0 0
>   c15t0d0s0  ONLINE   0 0 0
>   c16t0d0s0  DEGRADED 0 0 0  too many errors

This is an unmirrored pool consisting of two vdevs: c15t0d0s0 and c16t0d0s0.

Ronald
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Moving a ZFS root to another target

[andrew]

I've got an OpenSolaris system rooted on a SCSI disk at /dev/dsk/c4t1d0s0. I 
would like to reconfigure my VM so that this is on c4t0d0s0. Unfortunately 
OpenSolaris panics on boot when I do this. It seems that vfs_mountroot is 
trying to mount the root pool at its old device path (/[EMAIL 
PROTECTED],0/pci1000,[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a) which corresponds 
to /dev/dsk/c4t1d0s0. Where is this location hardcoded, and how do I change it? 
Also, is there any way to set up OpenSolaris so that this location is not 
hardcoded?

I took a screenshot of the panic:

http://sites.google.com/site/solarium/_/rsrc/1218841252931/zfs-screenshots/paniconboot.gif

Thanks

Andrew.
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Moving a ZFS root to another target

[andrew]

Hmm... Just tried the same thing on SXCE build 95 and it works fine. Strange. 
Anyone know what's up with OpenSolaris (the distro)? I'm using the ISO of 
OpenSolaris 208.11 snv_93 image-updated to build 95 if that makes a difference. 
I've not tried this on 2008.05 .

Thanks

Andrew.
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] C code for reading ZFS ACL

[Paul B. Henson]

I asked a while back if there was any utility function to evaluate a ZFS
ACL, I didn't get much of a response and was unable to find anything, so
decided to implement my own C code.

It appears the acl_get() function is a convenient way to read the ACL;
however, I don't see an efficient way to parse the data structure returned.

The function returns an "acl_t *", which is defined in  as
"typedef struct acl_info acl_t;"

The acl_info struct does not appear to be defined in any header files
shipped with Solaris 10. Browsing the opensolaris code base, I found the
definition in  to be:

struct acl_info {
 acl_type_t acl_type;   /* style of acl */
 int acl_cnt;   /* number of acl entries */
 int acl_entry_size;/* sizeof acl entry */
 int acl_flags; /* special flags about acl */
 void *acl_aclp;/* the acl */
};

Is the acl_t intentionally designed to be opaque? It seems the only thing I
can do with it is pass it to acltotext(), which will return a text string
describing the ACL.

It doesn't seem particularly efficient to pass a C structure to a function
that converts it to a string, and then use C code to parse the text string.

I would prefer to directly access the acl_info structure.

On the other hand, it appears all of the information necessary to use the
acl(2) system call is present with Solaris 10. However, that is a rather
raw and basic interface to the ACL, requiring some extra code wrapped
around it to make it useful.

The exact same code that's probably in acl_get(), and it seems redundant to
duplicate it.

So either I use the raw underlying system call, which is less than
desirable, or I use acl_get() but have to perform text parsing, which is
less than desirable.

I think I'm inclined to simply copy the data structure definition from
 into my code so I can access the acl_t directly, which
probably isn't recommended and will no doubt break if the internal
implementation changes; but it seems the effort to fix it when it breaks
would be less than either the effort to use the underlying system call or
the effort to parse the text.

Unless I'm missing something? Thanks for any feedback...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [EMAIL PROTECTED]
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Paul B. Henson wrote:
> I asked a while back if there was any utility function to evaluate a ZFS
> ACL, I didn't get much of a response and was unable to find anything, so
> decided to implement my own C code.
> 
> It appears the acl_get() function is a convenient way to read the ACL;
> however, I don't see an efficient way to parse the data structure returned.
> 
> The function returns an "acl_t *", which is defined in  as
> "typedef struct acl_info acl_t;"
> 
> The acl_info struct does not appear to be defined in any header files
> shipped with Solaris 10. Browsing the opensolaris code base, I found the
> definition in  to be:
> 
> struct acl_info {
>  acl_type_t acl_type; /* style of acl */
>  int acl_cnt; /* number of acl entries */
>  int acl_entry_size;  /* sizeof acl entry */
>  int acl_flags;   /* special flags about acl */
>  void *acl_aclp;  /* the acl */
> };
> 
> Is the acl_t intentionally designed to be opaque?

Yes, its meant to be opaque.

The layout of the acl_t will likely change in the not too distant future.

> can do with it is pass it to acltotext(), which will return a text string
> describing the ACL.
> 
> It doesn't seem particularly efficient to pass a C structure to a function
> that converts it to a string, and then use C code to parse the text string.
> 
> I would prefer to directly access the acl_info structure.
> 

There are a number of private interfaces in libsec to retrieve stuff out 
of the ACL, but they aren't documented interfaces, such as acl_data() 
which will return you the pointer to the array of ace_t's and acl_cnt() 
that will return you the number of ACEs in the array.  With those two 
interfaces you can then easily iterate over the ACL.

> So either I use the raw underlying system call, which is less than
> desirable, or I use acl_get() but have to perform text parsing, which is
> less than desirable.
> 
> I think I'm inclined to simply copy the data structure definition from
>  into my code so I can access the acl_t directly, which
> probably isn't recommended and will no doubt break if the internal
> implementation changes; but it seems the effort to fix it when it breaks
> would be less than either the effort to use the underlying system call or
> the effort to parse the text.
> 
> Unless I'm missing something? Thanks for any feedback...
> 
> 

We are currently investigating adding more functionality to libsec to 
provide many of the things you desire.  We will have iterators, editing 
capabilities and so on.

   -Mark


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Joe Blount]

  
Is the acl_t intentionally designed to be opaque?

  
  
Yes, its meant to be opaque.

The layout of the acl_t will likely change in the not too distant future.
  


Will old versions be supported?  For example, if ADM treats it as
opaque and archives the current format, after an upgrade (layout
change), could we write the old ACL to the new ZFS code?

thanks,
Joe


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Paul B. Henson]

On Fri, 15 Aug 2008, Mark Shellenbaum wrote:

> The layout of the acl_t will likely change in the not too distant future.
[...]
> of the ACL, but they aren't documented interfaces, such as acl_data()
> which will return you the pointer to the array of ace_t's and acl_cnt()
> that will return you the number of ACEs in the array.  With those two
> interfaces you can then easily iterate over the ACL.

Ah, thanks for the pointer. Reviewing the libsec code, I see there is also
acl_type(), and acl_flags(), but I don't see anything for accessing the
acl_entry_size. However, both aclent_t and ace_t are publicly documented so
sizeof() should do the trick.

Are the libsec undocumented interfaces likely to remain the same when the
acl_t structure changes? They will still require adding the prototypes to
my code so the compiler knows what to make of them, but less chance of
breakage is good.

> We are currently investigating adding more functionality to libsec to
> provide many of the things you desire.  We will have iterators, editing
> capabilities and so on.

Sweet. Might I request an acl evaluation function? Which basically, given a
user and a requested permission, returns either true (user has permission),
false (user doesn't have permission), or error condition. Similar to the
POSIX access() call, but for ACLs. If I had that I wouldn't need to be
mucking around with the ACL directly at all :), as that's basically what
I'm implementing...

Thanks much, I always appreciate your informative responses.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [EMAIL PROTECTED]
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Paul B. Henson]

On Fri, 15 Aug 2008, Paul B. Henson wrote:

> Ah, thanks for the pointer. Reviewing the libsec code, I see there is also
> acl_type()

Looks like the acl_type_t enum isn't in the public headers either though.
But presumably that's not likely to change...

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [EMAIL PROTECTED]
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Joe Blount wrote:
> 
>>> Is the acl_t intentionally designed to be opaque?
>>> 
>>
>> Yes, its meant to be opaque.
>>
>> The layout of the acl_t will likely change in the not too distant future.
>>   
> 
> Will old versions be supported?  For example, if ADM 
>  treats it as opaque and 
> archives the current format, after an upgrade (layout change), could we 
> write the old ACL to the new ZFS code?
> 
> thanks,
> Joe

acl_t is a purely in-core data structure, and is not appropriate for 
storing in an archive.  Thats what interfaces such as acl_totext() are 
for.  ADM should be archiving the ACL in a textual representation, much 
like tar/cpio do.

The interfaces such as acl_get()/acl_set() are merely convenience 
functions to make it easier for getting/setting ACLs without having to 
know if the file system is ZFS or UFS.  For example acl_get() knows how 
to determine if a file system supports POSIX draft ACLs or NFSv4 ACL and 
then uses the native acl(2) syscall to retrieve the data.


   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Mark Shellenbaum]

Paul B. Henson wrote:
> On Fri, 15 Aug 2008, Mark Shellenbaum wrote:
> 
>> The layout of the acl_t will likely change in the not too distant future.
> [...]
>> of the ACL, but they aren't documented interfaces, such as acl_data()
>> which will return you the pointer to the array of ace_t's and acl_cnt()
>> that will return you the number of ACEs in the array.  With those two
>> interfaces you can then easily iterate over the ACL.
> 
> Ah, thanks for the pointer. Reviewing the libsec code, I see there is also
> acl_type(), and acl_flags(), but I don't see anything for accessing the
> acl_entry_size. However, both aclent_t and ace_t are publicly documented so
> sizeof() should do the trick.
> 
> Are the libsec undocumented interfaces likely to remain the same when the
> acl_t structure changes? They will still require adding the prototypes to
> my code so the compiler knows what to make of them, but less chance of
> breakage is good.
> 

I can't guarantee they will remain in the future.  Thats why they aren't 
documented.

It may be that with appropriate iterators and other interfaces they will 
no longer be needed.

>> We are currently investigating adding more functionality to libsec to
>> provide many of the things you desire.  We will have iterators, editing
>> capabilities and so on.
> 
> Sweet. Might I request an acl evaluation function? Which basically, given a
> user and a requested permission, returns either true (user has permission),
> false (user doesn't have permission), or error condition. Similar to the
> POSIX access() call, but for ACLs. If I had that I wouldn't need to be
> mucking around with the ACL directly at all :), as that's basically what
> I'm implementing...
> 
> Thanks much, I always appreciate your informative responses.

Yep, the evaluation sort of thing is on our list of things to look into.

   -Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] C code for reading ZFS ACL

[Ian Collins]

Mark Shellenbaum wrote:
> Paul B. Henson wrote:
>>
>> Are the libsec undocumented interfaces likely to remain the same when the
>> acl_t structure changes? They will still require adding the prototypes to
>> my code so the compiler knows what to make of them, but less chance of
>> breakage is good.
>>
>> 
>
> I can't guarantee they will remain in the future.  Thats why they aren't 
> documented.
>
> It may be that with appropriate iterators and other interfaces they will 
> no longer be needed.
>
>   
I'm working on a similar problem to Paul (sorry I didn't get back to you
Paul - shifting priorities!), writing a PHP extension for ACLs, and I've
fallen into the trap of using acl_info.  Is this work you mention
happening in the open, or in side of Sun?  If it's the former, how can
we get involved?

Ian

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Oops: zpool detach from degraded mirror "only applicable to mirror ..

[Nils Goroll]

Hi all, especially Matthias,

I am very sorry for having bothered you with this stupid question, I am
embarrassed by the fact that I did not realize it's not a mirror. The
fact that I named it "rmirror" definitely added confusion on my side.

Apologies in particular for not having taken Mathias' initial hint for
what it was.

By the way, I could finally scrub the pool, no problems remaining
(except for the task to make it a real mirror).

Thanks again,

Nils
 
 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss