Re: [zfs-discuss] problem with zfs
Hum i know the recommended and the update patches bundles according to the readme Patch 139555-08 is the kernel patch associated with the Solaris 10 5/09 release (Solaris 10 Update 7). so i believe i'm up to date i understand i'm a bit vague but i cannot provide any Zpool or zfs output until i reboot. all the pools were created after the OS update just doing import, which is working . than doing a mount on the FS. the mountpoint is set to legacy so something like mount -F zfs POOL/FS /MOUNTPOINT it does work but from time to time (intermittant) the command hang there then nightmare starts am i alone to experiment this ? very hard to troubleshoot if i cannot execute any commands anyway i opened a case at Sun and not planning to reboot until they call me back -- 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] problem with zfs
serge goyette wrote: actually i did apply the latest recommended patches Recommended patches and upgrade clusters are different by the way. 10_Recommended != Upgrade Cluster that. Upgrade cluster will upgrade the system to a effectively the Solaris Release that the upgrade cluster is minus any new features that arrived in the newer OS release. SunOS VL-MO-ZMR01 5.10 Generic_139555-08 sun4v sparc SUNW,SPARC-Enterprise-T5120 but still perhaps you are not doing much import - export because when i do not do, i do not experience much problem but when doing it, outch ... Sure I import and export pools. But generally this is for moving the pool to another system. But I think we would need more information about the pool and it's file systems to be able to help you. Specifically maybe the output of 'zpool history' and 'zfs list' for starters. This will at least allow some specific data to try and help resolve your issues. The question as it stands is pretty generic. Have you upgraded your pools after the patches as well? 'zpool upgrade' and 'zfs upgrade' ? a reboot will solve until next time -sego- - ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] problem with zfs
actually i did apply the latest recommended patches SunOS VL-MO-ZMR01 5.10 Generic_139555-08 sun4v sparc SUNW,SPARC-Enterprise-T5120 but still perhaps you are not doing much import - export because when i do not do, i do not experience much problem but when doing it, outch ... a reboot will solve until next time -sego- -- 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] problem with zfs
The latest official Solaris 10 is actually 05/09. There are update patch bundles available on Sunsolve for free download that will take you to 05/09. It may well be worth applying these to see if they remedy the problem for you. They certainly allow you to bring ZFS up to version 10 from recollection. I have upgraded 30 plus systems with these and haven't experienced any issues. (both SPARC and x86) http://sunsolve.sun.com/pdownload.do?target=10_sparc_0509_patchbundle_part1.zip http://sunsolve.sun.com/pdownload.do?target=10_sparc_0509_patchbundle_part2.zip http://sunsolve.sun.com/pdownload.do?target=10_sparc_0509_patchbundle_part3.zip http://sunsolve.sun.com/pdownload.do?target=10_sparc_0509_patchbundle_part4.zip serge goyette wrote: for release sorry i meant Solaris 10 10/08 s10s_u6wos_07b SPARC Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 27 October 2008 -- ___ Scott Lawson Systems Architect Manukau Institute of Technology Information Communication Technology Services Private Bag 94006 Manukau City Auckland New Zealand Phone : +64 09 968 7611 Fax: +64 09 968 7641 Mobile : +64 27 568 7611 mailto:sc...@manukau.ac.nz http://www.manukau.ac.nz perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] problem with zfs
for release sorry i meant Solaris 10 10/08 s10s_u6wos_07b SPARC Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 27 October 2008 -- 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] Problem with zfs mounting in b114?
Miles, Miles Nordin wrote: >> "tn" == Thomas Nau writes: > > tn> After updating the machine to b114 we ran into a strange > tn> problem. The pool get's imported (listed by 'zpool list') but > tn> none of it's ZFS filesystems get mounted. Exporting and > tn> reimporting manually fixes the problem as does "zfs mount > tn> -a". So far it simply worked, as said till we updated. > > ``me, too'' with b71, so the symptom isn't new. > > I think this happens for me when the pool is UNAVAILABLE at boot, and > then enough devices come on line that it becomes ready. In that case > I need to do both zfs mount -a and zfs share -a. (or export/import) > > For me the main aspect of this problem is zfs mount mounting things in > the wrong order: some of the datasets are mounted but not all. If you > have nested filesystems, > > a/A > a/A/1 > a/A/2 > a/B > > sometimes you can end up with a/A/1, a/A/2, a/B mounted but a/A is not > mounted. In this case, the 'a' filesystem contains empty directories > serving as mountpoints a/A/1 and a/A/2, when it should contain only > mountpoint a/A (with the deeper two mountpoints inside the a/A > filesystem). You have to clear out the incorrect deeper mountpoints > before zfs mount -a will work properly again. > > so on second thought since you say none of your filesystems are > mounted, you may have a different symptom. That's strange. It always worked for us like a charm up till yesterday evening when the upgrade completed. We never ran into any issues you had. Thomas - GPG fingerprint: B1 EE D2 39 2C 82 26 DA A5 4D E0 50 35 75 9E ED ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with zfs mounting in b114?
> "tn" == Thomas Nau writes:
tn> After updating the machine to b114 we ran into a strange
tn> problem. The pool get's imported (listed by 'zpool list') but
tn> none of it's ZFS filesystems get mounted. Exporting and
tn> reimporting manually fixes the problem as does "zfs mount
tn> -a". So far it simply worked, as said till we updated.
``me, too'' with b71, so the symptom isn't new.
I think this happens for me when the pool is UNAVAILABLE at boot, and
then enough devices come on line that it becomes ready. In that case
I need to do both zfs mount -a and zfs share -a. (or export/import)
For me the main aspect of this problem is zfs mount mounting things in
the wrong order: some of the datasets are mounted but not all. If you
have nested filesystems,
a/A
a/A/1
a/A/2
a/B
sometimes you can end up with a/A/1, a/A/2, a/B mounted but a/A is not
mounted. In this case, the 'a' filesystem contains empty directories
serving as mountpoints a/A/1 and a/A/2, when it should contain only
mountpoint a/A (with the deeper two mountpoints inside the a/A
filesystem). You have to clear out the incorrect deeper mountpoints
before zfs mount -a will work properly again.
so on second thought since you say none of your filesystems are
mounted, you may have a different symptom.
--
READ CAREFULLY. By reading this fortune, you agree, on behalf of your employer,
to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap,
browsewrap, confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its
partners, licensors, agents and assigns, in perpetuity, without prejudice to my
ongoing rights and privileges. You further represent that you have the
authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
pgpQcBMKimaE4.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Mark Shellenbaum wrote: > > Nope, but you should be able to just use access(2) to determine if you > > need to add the ACL entry. > > > > But that probably won't work since you won't be running as that user yet > and access(2) would be checking off of a privileged cred. For this purpose, POSIX propsed eaccess() and Solaris has the flag E_OK. access(2) was designed to allow suid processec to check whether they would be able to access a file in case they have not been called suid. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On Thu, Dec 11, 2008 at 04:46:33PM -0700, Mark Shellenbaum wrote: > Mark Shellenbaum wrote: > >>> You should probably make sure that you just don't keep continually > >>> adding the same entry over and over again to the ACL. With NFSv4 ACLs > >>> you can insert the same entry multiple times and if you keep doing it > >>> long enough you will eventually get an error back when you reach the > >>> ACE limit on the file. > >> Note that logindevperm will reset the ownership and permission of the > >> file each time a user logs in or out. I guess I was assuming this would > >> reset the ACL's as well. Is this not the case? > >> > > > > Yes, it also changes the owner and group. > > > >> At any rate, it wouldn't hurt to check to see if the ACL is there already. > >> Do you have a code example that shows how to do that? > >> > > > > Nope, but you should be able to just use access(2) to determine if you > > need to add the ACL entry. > > > > But that probably won't work since you won't be running as that user yet > and access(2) would be checking off of a privileged cred. It'd be easy to use setreuid() to set the real UID to be gdm's. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Mark Shellenbaum wrote: >>> You should probably make sure that you just don't keep continually >>> adding the same entry over and over again to the ACL. With NFSv4 ACLs >>> you can insert the same entry multiple times and if you keep doing it >>> long enough you will eventually get an error back when you reach the >>> ACE limit on the file. >> Note that logindevperm will reset the ownership and permission of the >> file each time a user logs in or out. I guess I was assuming this would >> reset the ACL's as well. Is this not the case? >> > > Yes, it also changes the owner and group. > >> At any rate, it wouldn't hurt to check to see if the ACL is there already. >> Do you have a code example that shows how to do that? >> > > Nope, but you should be able to just use access(2) to determine if you > need to add the ACL entry. > But that probably won't work since you won't be running as that user yet and access(2) would be checking off of a privileged cred. -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
>> You should probably make sure that you just don't keep continually >> adding the same entry over and over again to the ACL. With NFSv4 ACLs >> you can insert the same entry multiple times and if you keep doing it >> long enough you will eventually get an error back when you reach the >> ACE limit on the file. > > Note that logindevperm will reset the ownership and permission of the > file each time a user logs in or out. I guess I was assuming this would > reset the ACL's as well. Is this not the case? > Yes, it also changes the owner and group. > At any rate, it wouldn't hurt to check to see if the ACL is there already. > Do you have a code example that shows how to do that? > Nope, but you should be able to just use access(2) to determine if you need to add the ACL entry. >> There is code in libdevinfo called setdevaccess() that will strip off >> all ACEs on a device file via acl_strip(3sec). The setdevaccess() >> interface is called by di_devperm_login(). Does gdm use that interface? > > Yes, does this mean that the ACL's are getting reset anyway each time a > user logs in? If so, then I don't think there is a real need to worry > about the ACL list getting too long. Since logindevperm is only used > for console login, there wouldn't be any issues (for example) in a > Sun Ray environment where multiple login screens would be showing > and calling the ACL list at the same time. > > Brian > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Mark: > You could call acl(2) directly, but you would have to construct a > complete ACL to set. It would be easier to use acl_get() and acl_set() > which understand the various ACL flavors and will call the syscall with > correct ACL flavor arguments. > > Unfortunately, what you are wanting to do is retrieve the ACL, prepend > an entry and then call acl_set(). There is a private interface in > libsec called acl_addentries() that can do such a thing, but that > interface could change and I'm not sure I would recommend using it since > gdm isn't in ON. Also, acl_entries needs the added ACE entries to be in > raw ace_t format and not the textual representation you are setting with > chmod(1). We definately need some better ACL interfaces for this sort > of thing. Hmmm, calling system() is not looking like such a bad solution after all. > You should probably make sure that you just don't keep continually > adding the same entry over and over again to the ACL. With NFSv4 ACLs > you can insert the same entry multiple times and if you keep doing it > long enough you will eventually get an error back when you reach the ACE > limit on the file. Note that logindevperm will reset the ownership and permission of the file each time a user logs in or out. I guess I was assuming this would reset the ACL's as well. Is this not the case? At any rate, it wouldn't hurt to check to see if the ACL is there already. Do you have a code example that shows how to do that? > There is code in libdevinfo called setdevaccess() that will strip off > all ACEs on a device file via acl_strip(3sec). The setdevaccess() > interface is called by di_devperm_login(). Does gdm use that interface? Yes, does this mean that the ACL's are getting reset anyway each time a user logs in? If so, then I don't think there is a real need to worry about the ACL list getting too long. Since logindevperm is only used for console login, there wouldn't be any issues (for example) in a Sun Ray environment where multiple login screens would be showing and calling the ACL list at the same time. Brian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Brian Cameron wrote:
> Mark & Others:
>
>> I think you may have misunderstood what people were suggesting. They
>> weren't suggesting changing the mode of the file, but using chmod(1M) to
>> add/modify ZFS ACLs on the device file.
>>
>> chmod A+user:gdm:rwx:allow
>>
>> See chmod(1M) or the zfs admin guide for ZFS ACL examples.
>
> Thanks for your help. Now GDM is using the following code to set ACL's
> (spacing slightly modified for readability):
>
> {
> int acl_flavor;
> acl_flavor = pathconf("/dev/audio", _PC_ACL_ENABLED);
>
> if (acl_flavor & _ACL_ACLENT_ENABLED) {
> system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
> /dev/audio");
> system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
> /dev/audioctl");
> } else if (acl_flavor & _ACL_ACE_ENABLED) {
> system ("/usr/bin/chmod A+user:gdm:rwx:allow
> /dev/audio");
> system ("/usr/bin/chmod A+user:gdm:rwx:allow
> /dev/audioctl");
> }
> }
>
> That works much better, and now GDM text-to-speech works much better on
> ZFS filesystems.
>
> However, now I am wondering if it might be better to call acl(2) functions
> rather than spawning off new processes via system(). Does setfacl(2), for
> exmaple, work with both flavors, or would I need to call different functions
> based on the acl_flavor? I am not very familiar with working with
> acl's, so any help explaining how to modify the above code to use acl
> functions rather than calling system would be helpful.
>
> Thanks,
>
You could call acl(2) directly, but you would have to construct a
complete ACL to set. It would be easier to use acl_get() and acl_set()
which understand the various ACL flavors and will call the syscall with
correct ACL flavor arguments.
Unfortunately, what you are wanting to do is retrieve the ACL, prepend
an entry and then call acl_set(). There is a private interface in
libsec called acl_addentries() that can do such a thing, but that
interface could change and I'm not sure I would recommend using it since
gdm isn't in ON. Also, acl_entries needs the added ACE entries to be in
raw ace_t format and not the textual representation you are setting with
chmod(1). We definately need some better ACL interfaces for this sort
of thing.
You should probably make sure that you just don't keep continually
adding the same entry over and over again to the ACL. With NFSv4 ACLs
you can insert the same entry multiple times and if you keep doing it
long enough you will eventually get an error back when you reach the ACE
limit on the file.
There is code in libdevinfo called setdevaccess() that will strip off
all ACEs on a device file via acl_strip(3sec). The setdevaccess()
interface is called by di_devperm_login(). Does gdm use that interface?
-Mark
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Mark & Others:
> I think you may have misunderstood what people were suggesting. They
> weren't suggesting changing the mode of the file, but using chmod(1M) to
> add/modify ZFS ACLs on the device file.
>
> chmod A+user:gdm:rwx:allow
>
> See chmod(1M) or the zfs admin guide for ZFS ACL examples.
Thanks for your help. Now GDM is using the following code to set ACL's
(spacing slightly modified for readability):
{
int acl_flavor;
acl_flavor = pathconf("/dev/audio", _PC_ACL_ENABLED);
if (acl_flavor & _ACL_ACLENT_ENABLED) {
system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
/dev/audio");
system ("/usr/bin/setfacl -m user:gdm:rwx,mask:rwx
/dev/audioctl");
} else if (acl_flavor & _ACL_ACE_ENABLED) {
system ("/usr/bin/chmod A+user:gdm:rwx:allow
/dev/audio");
system ("/usr/bin/chmod A+user:gdm:rwx:allow
/dev/audioctl");
}
}
That works much better, and now GDM text-to-speech works much better on
ZFS filesystems.
However, now I am wondering if it might be better to call acl(2) functions
rather than spawning off new processes via system(). Does setfacl(2), for
exmaple, work with both flavors, or would I need to call different functions
based on the acl_flavor? I am not very familiar with working with
acl's, so any help explaining how to modify the above code to use acl
functions rather than calling system would be helpful.
Thanks,
Brian
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On Tue, Dec 09, 2008 at 09:09:15AM +0100, [EMAIL PROTECTED] wrote: > >When I switch away from a session where programs are producing sound > >what should happen is this: a) those programs continue to operate, b) > >but they don't produce actual sound until I switch back to that VT (and > >unlock the screen). > > I'm not sure why the programs should stop; it's just as valid to > throw the output away. I didn't mean that they should stop -- they should continue, but their sound output should be muted. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
>On Mon, Dec 08, 2008 at 04:46:37PM -0600, Brian Cameron wrote: >> >Is there a shortcomming in VT here? >> >> I guess it depends on how you think VT should work. My understanding >> is that VT works on a first-come-first-serve basis, so the first user >> who calls logindevperm interfaces gets permission. While it might seem >> nicer for the last user to get the device, this is much harder to manage. > >No, I think audio should be virtualized. The current session should >have access to the real audio hardware, and the others should not be >able to produce sound (though as afar as apps go, they shouldn't know >the difference). I think we talked about this at the time but in the end we made a vt subsystem which works like others do. But I agree with you. It doesn't necessarily virtualizing /dev/audio, adding but adding $AUDIODEV to the environment of such a session. (E.g., /dev/vt/sound/...). At this time, it seems that the last one to login gets /dev/sound? >> Making it work the other way would require logindevperm to be enhanced. > >Perhaps. It will also require virtualizing the audio device. And possibly not, because a simple rule can be used if we give the virtualized audio a different device node. >When I switch away from a session where programs are producing sound >what should happen is this: a) those programs continue to operate, b) >but they don't produce actual sound until I switch back to that VT (and >unlock the screen). I'm not sure why the programs should stop; it's just as valid to throw the output away. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On Mon, Dec 08, 2008 at 04:46:37PM -0600, Brian Cameron wrote:
> >Is there a shortcomming in VT here?
>
> I guess it depends on how you think VT should work. My understanding
> is that VT works on a first-come-first-serve basis, so the first user
> who calls logindevperm interfaces gets permission. While it might seem
> nicer for the last user to get the device, this is much harder to manage.
No, I think audio should be virtualized. The current session should
have access to the real audio hardware, and the others should not be
able to produce sound (though as afar as apps go, they shouldn't know
the difference).
> Making it work the other way would require logindevperm to be enhanced.
Perhaps. It will also require virtualizing the audio device.
> Also, I think it gets complicated to manage if the first user has
> programs running which are using the audio device, or other devices
> managed by logindevperm. How to manage unconnecting them when a VT
> switch happens, and then reconnecting them when switching back would
> be complicated and probably error-prone.
When I switch away from a session where programs are producing sound
what should happen is this: a) those programs continue to operate, b)
but they don't produce actual sound until I switch back to that VT (and
unlock the screen).
> At any rate, I think it would be a pretty significant enhancement to
> the existing interfaces to support this sort of behavior.
>
> If you are interested, you can discuss this further with the VT team
> if you want to make suggestions about how this should all work.
> [EMAIL PROTECTED] is the engineer working on VT, and would be the
> right person to talk to.
OK, I will! Thanks for the contact.
> >I didn't realize that we had A11Y support in S10's GDM! I thought that
> >was one of the problems with it. How do you configure A11Y for GDM? I
> >would really like to enable sticky keys at the GDM screen.
>
> When I have been talking about to a11y in GDM, I have been referring to the
> ability to start AT programs such as orca or GOK. Xserver a11y features
> like sticky keys should "just work" if you enable them via keyboard
> shortcuts. I believe hitting the Shift key five times in a row enables
> Sticky Keys. I am not sure if this keyboard shortcut is available by
> default or not in GDM.
I'll try it tonight.
> >So methinks there needs to at least be a comment in logindevperm code to
> >guard against someone causing it to clobber GDM's ACL entry. The ARC
> >might care to know too; ask a member.
>
> Thanks, I overlooked bringing this up to ARC. I will make sure that the
> GDM usage of these interfaces is ARC'ed before VT is enabled in the Solaris
> Xserver and GDM. This really only becomes something to care about after
> that happens.
OK, but sending a comment now wouldn't hurt ("ARC early, ARC often").
Nico
--
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Nicolas: > On Mon, Dec 08, 2008 at 03:27:49PM -0600, Brian Cameron wrote: >> login, they get the audio device. Then you can use VT switching in GDM >> to start up a second graphical login. If this user needs text-to-speech, >> they are out of luck since they can't access the audio device from their >> user session regardless if they can log in. At any rate, VT is not yet >> enabled in the Xserver or GDM, so there really isn't an issue that needs >> to be addressed until this is integrated and working in Solaris. > > Well, shouldn't this mean that /dev/audio should get virtuallized so > that it's as /dev/null when the console is switched to a different VT, > so only the current VT ever has access to the real /dev/audio? > > Is there a shortcomming in VT here? I guess it depends on how you think VT should work. My understanding is that VT works on a first-come-first-serve basis, so the first user who calls logindevperm interfaces gets permission. While it might seem nicer for the last user to get the device, this is much harder to manage. Making it work the other way would require logindevperm to be enhanced. I believe this is because logindevperm only has interfaces to indicate a user has logged in or out, and does not support any way to inform logindevperm that a user switch has happened. Also, I think it gets complicated to manage if the first user has programs running which are using the audio device, or other devices managed by logindevperm. How to manage unconnecting them when a VT switch happens, and then reconnecting them when switching back would be complicated and probably error-prone. At any rate, I think it would be a pretty significant enhancement to the existing interfaces to support this sort of behavior. If you are interested, you can discuss this further with the VT team if you want to make suggestions about how this should all work. [EMAIL PROTECTED] is the engineer working on VT, and would be the right person to talk to. >> Console login also does use logindevperm, so you could also have this >> problem if a user logged into a text console, then started GDM. Though >> this would be an odd usage of the system. If a user were to do this, >> they shouldn't be surprised if it doesn't work properly. > > I would be! If you log into the console first, then it calls logindevperm interfaces first and wins. Any graphical logins would not get permission, unless (of course) you logged into the same user as you used when logging into the console. At any rate, now that you know, you will not be surprised. :) >> Perhaps I should explain the history of this a bit, just so you understand >> how the code has evolved. In Solaris 10, GDM used logindevperm to give the >> ... > > I didn't realize that we had A11Y support in S10's GDM! I thought that > was one of the problems with it. How do you configure A11Y for GDM? I > would really like to enable sticky keys at the GDM screen. When I have been talking about to a11y in GDM, I have been referring to the ability to start AT programs such as orca or GOK. Xserver a11y features like sticky keys should "just work" if you enable them via keyboard shortcuts. I believe hitting the Shift key five times in a row enables Sticky Keys. I am not sure if this keyboard shortcut is available by default or not in GDM. You might need to setup your Xserver configuration or the Xserver arguments used when GDM starts the Xserver in the GDM configuration to make this work. There is probably also some Xserver interfaces you could use to configure it to just always be on by default, though I am not sure how to do that. You would need to refer to the Xserver documentation. >> The login GUI is run with limited privilege. > > Ah, OK. > > So methinks there needs to at least be a comment in logindevperm code to > guard against someone causing it to clobber GDM's ACL entry. The ARC > might care to know too; ask a member. Thanks, I overlooked bringing this up to ARC. I will make sure that the GDM usage of these interfaces is ARC'ed before VT is enabled in the Solaris Xserver and GDM. This really only becomes something to care about after that happens. I do appreciate you helping me to make sure we integrate all of this properly. Brian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On Mon, Dec 08, 2008 at 03:27:49PM -0600, Brian Cameron wrote: > Once VT is enabled in the Xserver and GDM, users can start multiple > graphical logins with GDM. So, if a user logs into the first graphical Ah, right, I'd forgotten this. > login, they get the audio device. Then you can use VT switching in GDM > to start up a second graphical login. If this user needs text-to-speech, > they are out of luck since they can't access the audio device from their > user session regardless if they can log in. At any rate, VT is not yet > enabled in the Xserver or GDM, so there really isn't an issue that needs > to be addressed until this is integrated and working in Solaris. Well, shouldn't this mean that /dev/audio should get virtuallized so that it's as /dev/null when the console is switched to a different VT, so only the current VT ever has access to the real /dev/audio? Is there a shortcomming in VT here? > Console login also does use logindevperm, so you could also have this > problem if a user logged into a text console, then started GDM. Though > this would be an odd usage of the system. If a user were to do this, > they shouldn't be surprised if it doesn't work properly. I would be! > Perhaps I should explain the history of this a bit, just so you understand > how the code has evolved. In Solaris 10, GDM used logindevperm to give the > ... I didn't realize that we had A11Y support in S10's GDM! I thought that was one of the problems with it. How do you configure A11Y for GDM? I would really like to enable sticky keys at the GDM screen. > >No, that's not the problem I care about. The problem I care about is: > >how to make sure that logindevperm never gets modified to set devices' > >ACLs in any way that might trample on GDM's ACL entries. > > Yes, that makes sense. > > ... > > The login GUI is run with limited privilege. Ah, OK. So methinks there needs to at least be a comment in logindevperm code to guard against someone causing it to clobber GDM's ACL entry. The ARC might care to know too; ask a member. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Nicolas: >> I agree that the solution of GDM messing with ACL's is not an ideal >> solution. No matter how we resolve this problem, I think a scenario >> could be imagined where the audio would not be managed as expected. >> This is because if multiple users are competing for the same audio >> device, then a user with a11y text-to-speech issues can easily find >> themselves in a situation where they can't use audio in their session >> because another user has already acquired it. Even if GDM allows you >> to log in with text-to-speech, this is not really useful if you can >> not use the audio device once you have logged into your session. > > How would that happen? Aren't we trying hard to associate individual > devices with individual seats? Or is there some issue where a login on > a VT console could steal devices from a login on a graphical console? > > (I could see how that could happen, but that seems like a serious bug to > me: text logins shouldn't need to acquire /dev/audio and friends, unless > specifically configured to do so. But in any case, it doesn't matter > much since in the VT case there's a single physical seat, so the user > would have to be purposefully trying to excercise a GDM vs login(1) > race.) Once VT is enabled in the Xserver and GDM, users can start multiple graphical logins with GDM. So, if a user logs into the first graphical login, they get the audio device. Then you can use VT switching in GDM to start up a second graphical login. If this user needs text-to-speech, they are out of luck since they can't access the audio device from their user session regardless if they can log in. At any rate, VT is not yet enabled in the Xserver or GDM, so there really isn't an issue that needs to be addressed until this is integrated and working in Solaris. Console login also does use logindevperm, so you could also have this problem if a user logged into a text console, then started GDM. Though this would be an odd usage of the system. If a user were to do this, they shouldn't be surprised if it doesn't work properly. >> Note this is not really an issue with Sun Ray since each Sun Ray >> device has their own audio pseudo-device and users are not competing >> for the same device. These logindevperm issues is only a concern for users >> logging in via the console (with VT or otherwise). > > Right. I find it odd that we use a different device allocation > mechanism for console vs. SunRay logins, but that's a different story. Sun Ray devices don't use logindevperm, since logindevperm is used just for the console. On Sun Ray, each device has their own audio interface as defined by the AUDIODEV environment variable. >> Really, the purpose of using ACL's is to give GDM access to the audio >> device in the normal use-case where a user with accessibility needs >> is not competing with other users for the audio device. It is a nice >> technique to use since it doesn't confuse logindevperm by changing the >> actual ownership/permissions of the device files. > > Because logindevperm isn't resetting the ACL. But how do you prevent > another engineer from adding code to do that at some future point? > That's what my comment about ARCing this was about. Perhaps I should explain the history of this a bit, just so you understand how the code has evolved. In Solaris 10, GDM used logindevperm to give the gdm user access to the audio device. When the GDM login GUI started up, it called logindevperm interfaces to give the "gdm" user access to the audio device. Then when a user logged in, it would unset the "gdm" user via logindevperm interfaces, and then call logindevperm as the user who is going to log in to give them permission. Likewise when the user logged out, it would unset that user and give the devices back to the gdm user via logindevperm interfaces. This worked fine before VT was introduced into Solaris since only one GDM process could be running on the console at a time. When we started preparing GDM to work with VT, we had to change this. We modified GDM to use ACL's recently because it works in a way that is more compatible with how logindevperm works when VT is being used to support multiple graphical logins. Since GDM is being rewritten, and we plan to integrate the rewritten GDM into Solaris soon, would it be acceptable to ARC this when we integrate the new GDM, or do you think it needs to be ARC'ed more immediately? >> If we want to try to solve the bigger problem of how text-to-speech >> should work when users are competing for the same audio device, then that >> is a much bigger problem, I think. I do not think this is a very common > > No, that's not the problem I care about. The problem I care about is: > how to make sure that logindevperm never gets modified to set devices' > ACLs in any way that might trample on GDM's ACL entries. Yes, that makes sense. >>> Alternatively, can't GDM open the devices it needs before dropping >>> privileges? It doe
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On Mon, Dec 08, 2008 at 02:22:01PM -0600, Brian Cameron wrote: > >That said, I don't see why di_devperm_login() couldn't stomp all over > >the ACL too. So you'll need to make sure that di_devperm_login() > >doesn't stomp over the ACL, which will probably mean running an ARC case > >and updating the logindevperm(4) manpage. > > I agree that the solution of GDM messing with ACL's is not an ideal > solution. No matter how we resolve this problem, I think a scenario > could be imagined where the audio would not be managed as expected. > This is because if multiple users are competing for the same audio > device, then a user with a11y text-to-speech issues can easily find > themselves in a situation where they can't use audio in their session > because another user has already acquired it. Even if GDM allows you > to log in with text-to-speech, this is not really useful if you can > not use the audio device once you have logged into your session. How would that happen? Aren't we trying hard to associate individual devices with individual seats? Or is there some issue where a login on a VT console could steal devices from a login on a graphical console? (I could see how that could happen, but that seems like a serious bug to me: text logins shouldn't need to acquire /dev/audio and friends, unless specifically configured to do so. But in any case, it doesn't matter much since in the VT case there's a single physical seat, so the user would have to be purposefully trying to excercise a GDM vs login(1) race.) > Note this is not really an issue with Sun Ray since each Sun Ray > device has their own audio pseudo-device and users are not competing > for the same device. These logindevperm issues is only a concern for users > logging in via the console (with VT or otherwise). Right. I find it odd that we use a different device allocation mechanism for console vs. SunRay logins, but that's a different story. > Really, the purpose of using ACL's is to give GDM access to the audio > device in the normal use-case where a user with accessibility needs > is not competing with other users for the audio device. It is a nice > technique to use since it doesn't confuse logindevperm by changing the > actual ownership/permissions of the device files. Because logindevperm isn't resetting the ACL. But how do you prevent another engineer from adding code to do that at some future point? That's what my comment about ARCing this was about. > If we want to try to solve the bigger problem of how text-to-speech > should work when users are competing for the same audio device, then that > is a much bigger problem, I think. I do not think this is a very common No, that's not the problem I care about. The problem I care about is: how to make sure that logindevperm never gets modified to set devices' ACLs in any way that might trample on GDM's ACL entries. > [...] > > The main reason this issue came up is because Indiana uses ZFS, and > the ACL's that GDM use obviously stopped working, and this caused > text-to-speech stopped working when using GDM on Indiana. I mainly needed > help to figure out how to use ACL's with ZFS so GDM can work on Indiana > as well as it does on Nevada. Or perhaps the reason it came up is that GDM was doing something that noone knew it was doing. (I'm not sure, and I don't care which is the case.) Thus the concern about making sure this doesn't come up again. > >Alternatively, can't GDM open the devices it needs before dropping > >privileges? It does run with all [zone] privileges, after all. > > This might be possible, but I do not think it would be easy. Note that > the root-running GDM daemon runs the login GUI as the "gdm" user. But with all [zone] privileges, right? > Then AT programs (such as orca) are launched via a11y interfaces > by the login program (if GDM is configured with a11y turned on). With or without privilege? > Coming up with some mechanism so that the root-running daemon opened > the device and somehow passed this file-handle off to a subprocess running > as a different user seems tricky. Nah, just pass the necessary privileges and let the AT programs drop them after opening the devices. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Nicholas: > On Sun, Dec 07, 2008 at 03:20:01PM -0600, Brian Cameron wrote: >> Thanks for the information. Unfortunately, using chmod/chown does not >> seem a workable solution to me, unless I am missing something. Normally >> logindevperm(4) is used for managing the ownership and permissions of >> device files (like the audio device), and if the GDM daemon just calls >> chown/chmod on the audio device, then it seems this could easily cause >> inconsistencies with logindevperm. > > As Mark replied, chmod(1) isn't just for setting file permissions, but > also for ACL manipulation. Yes, sorry for being thick, and thanks to everyone for explaining things. I think I understand better now. > That said, I don't see why di_devperm_login() couldn't stomp all over > the ACL too. So you'll need to make sure that di_devperm_login() > doesn't stomp over the ACL, which will probably mean running an ARC case > and updating the logindevperm(4) manpage. I agree that the solution of GDM messing with ACL's is not an ideal solution. No matter how we resolve this problem, I think a scenario could be imagined where the audio would not be managed as expected. This is because if multiple users are competing for the same audio device, then a user with a11y text-to-speech issues can easily find themselves in a situation where they can't use audio in their session because another user has already acquired it. Even if GDM allows you to log in with text-to-speech, this is not really useful if you can not use the audio device once you have logged into your session. Note this is not really an issue with Sun Ray since each Sun Ray device has their own audio pseudo-device and users are not competing for the same device. These logindevperm issues is only a concern for users logging in via the console (with VT or otherwise). Really, the purpose of using ACL's is to give GDM access to the audio device in the normal use-case where a user with accessibility needs is not competing with other users for the audio device. It is a nice technique to use since it doesn't confuse logindevperm by changing the actual ownership/permissions of the device files. If we want to try to solve the bigger problem of how text-to-speech should work when users are competing for the same audio device, then that is a much bigger problem, I think. I do not think this is a very common use-case, though. GDM has pretty much worked the same way since Solaris 10, and I have never had a user complain about this sort of issue. Though this could perhaps become more of an issue when VT usage becomes more popular. That said, Linux distros have the same problem. The main reason this issue came up is because Indiana uses ZFS, and the ACL's that GDM use obviously stopped working, and this caused text-to-speech stopped working when using GDM on Indiana. I mainly needed help to figure out how to use ACL's with ZFS so GDM can work on Indiana as well as it does on Nevada. > Alternatively, can't GDM open the devices it needs before dropping > privileges? It does run with all [zone] privileges, after all. This might be possible, but I do not think it would be easy. Note that the root-running GDM daemon runs the login GUI as the "gdm" user. Then AT programs (such as orca) are launched via a11y interfaces by the login program (if GDM is configured with a11y turned on). Coming up with some mechanism so that the root-running daemon opened the device and somehow passed this file-handle off to a subprocess running as a different user seems tricky. >> Remember, for example, that multiple users can login into the same >> machine. Perhaps one via the console, and other users via XDMCP or >> other remote methods. VT (Virtual Terminal) will soon integrate >> into Solaris and add yet another way that users can log in. > > VT is in *now* and has been for a few builds. Sort of. VT is in the kernel, but not yet enabled in the Xserver. It also is not turned on via SMF by default. From GDM's perspective, VT isn't really useful if it isn't supported by the Xserver. Thus VT is not supported by GDM currently either. I understand VT will be enabled in the Xserver sometime in the next quarter. Once that is done, then VT will be fully supported on Solaris. Brian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On Sun, Dec 07, 2008 at 03:20:01PM -0600, Brian Cameron wrote: > Thanks for the information. Unfortunately, using chmod/chown does not > seem a workable solution to me, unless I am missing something. Normally > logindevperm(4) is used for managing the ownership and permissions of > device files (like the audio device), and if the GDM daemon just calls > chown/chmod on the audio device, then it seems this could easily cause > inconsistencies with logindevperm. As Mark replied, chmod(1) isn't just for setting file permissions, but also for ACL manipulation. That said, I don't see why di_devperm_login() couldn't stomp all over the ACL too. So you'll need to make sure that di_devperm_login() doesn't stomp over the ACL, which will probably mean running an ARC case and updating the logindevperm(4) manpage. Alternatively, can't GDM open the devices it needs before dropping privileges? It does run with all [zone] privileges, after all. > Remember, for example, that multiple users can login into the same > machine. Perhaps one via the console, and other users via XDMCP or > other remote methods. VT (Virtual Terminal) will soon integrate > into Solaris and add yet another way that users can log in. VT is in *now* and has been for a few builds. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
> > ACL's seemed a good solution since it leaves the overall ownership > and permissions of the device the same, but just adds the gdm user as > having permission to access the device as needed. Is there any way to > get this same sort of behavior when using ZFS. > I think you may have misunderstood what people were suggesting. They weren't suggesting changing the mode of the file, but using chmod(1M) to add/modify ZFS ACLs on the device file. chmod A+user:gdm:rwx:allow See chmod(1M) or the zfs admin guide for ZFS ACL examples. > If not, can people recommend a better way to manage audio device > permisisons from the login screen? I know on some Linux distros, > they make the audio device owned by the "audio" group and ensure that > the "gdm" user is in the audio group. Perhaps we should use a similar > approach on Solaris if ACL isn't a practical solution for all file > systems. > > Remember that the need to have access to the audio device from the login > screen is only used to support text-to-speech so that users with certain > accessibility needs can navigate the login screen. In other words, it is > a feature that only a small percentage of users really need, but a > feature that makes the desktop completely unusable for them if it is not > present. > > Thoughts? > > Thanks again for all the help, > > Brian > > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
Mark/Tomas/Miles: Thanks for the information. Unfortunately, using chmod/chown does not seem a workable solution to me, unless I am missing something. Normally logindevperm(4) is used for managing the ownership and permissions of device files (like the audio device), and if the GDM daemon just calls chown/chmod on the audio device, then it seems this could easily cause inconsistencies with logindevperm. Remember, for example, that multiple users can login into the same machine. Perhaps one via the console, and other users via XDMCP or other remote methods. VT (Virtual Terminal) will soon integrate into Solaris and add yet another way that users can log in. It seems that it would cause obvious problems if the GDM daemon simply changed the ownership/permissions of the audio device files when starting the GUI login screen. What if a second user tries to log in via XDMCP after another user has already logged in, has ownership of the audio device, and is using it? We probably don't want the second login screen to steal the audio device away from the first user. Also, making the file have "all user" read/write permissions is not desirable since it would make a denial-of-service attack simple, where a second user could take over the audio device. ACL's seemed a good solution since it leaves the overall ownership and permissions of the device the same, but just adds the gdm user as having permission to access the device as needed. Is there any way to get this same sort of behavior when using ZFS. If not, can people recommend a better way to manage audio device permisisons from the login screen? I know on some Linux distros, they make the audio device owned by the "audio" group and ensure that the "gdm" user is in the audio group. Perhaps we should use a similar approach on Solaris if ACL isn't a practical solution for all file systems. Remember that the need to have access to the audio device from the login screen is only used to support text-to-speech so that users with certain accessibility needs can navigate the login screen. In other words, it is a feature that only a small percentage of users really need, but a feature that makes the desktop completely unusable for them if it is not present. Thoughts? Thanks again for all the help, Brian Mark Shellenbaum wrote: > >> However, I notice that when using ZFS on Indiana the above commands fail >> with the following error: >> >>File system doesn't support aclent_t style ACL's. >>See acl(5) for more information on ACL styles support by Solaris. >> >> What is the appropriate command to use with ZFS? > > You can use pathconf() with _PC_ACL_ENABLED to determine what flavor of > ACL the file system supports. > > check out these links. > > http://docs.sun.com/app/docs/doc/816-5167/fpathconf-2?a=view > http://blogs.sun.com/alvaro/entry/detecting_the_acl_type_you > > The example in the blog isn't quite correct. The returned value is a > bit mask, and it is possible for a file system to support multiple ACL > flavors. > > Here is an example of pathconf() as used in acl_strip(3sec) > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsec/common/aclutils.c#390 > > > > > -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
> However, I notice that when using ZFS on Indiana the above commands fail > with the following error: > >File system doesn't support aclent_t style ACL's. >See acl(5) for more information on ACL styles support by Solaris. > > What is the appropriate command to use with ZFS? You can use pathconf() with _PC_ACL_ENABLED to determine what flavor of ACL the file system supports. check out these links. http://docs.sun.com/app/docs/doc/816-5167/fpathconf-2?a=view http://blogs.sun.com/alvaro/entry/detecting_the_acl_type_you The example in the blog isn't quite correct. The returned value is a bit mask, and it is possible for a file system to support multiple ACL flavors. Here is an example of pathconf() as used in acl_strip(3sec) http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsec/common/aclutils.c#390 -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Problem with ZFS and ACL with GDM
On 05 December, 2008 - Brian Cameron sent me these 1,5K bytes:
>
> I am the maintainer of GDM, and I am noticing that GDM has a problem when
> running on a ZFS filesystem, as with Indiana.
>
> When GDM (the GNOME Display Manager) starts the login GUI, it runs the
> following commands on Solaris:
>
>/usr/bin/setfacl -m user:gdm:rwx,mask:rwx /dev/audio
>/usr/bin/setfacl -m user:gdm:rwx,mask:rwx /dev/audioctl
>
> It does this because the login GUI programs are run as the "gdm" user,
> and in order to support text-to-speech via orca, for users with
> accessibility needs, the "gdm" user needs access to the audio device.
> We were using setfacl because logindevperm(3) normally manages the
> audio device permissions and we only want the "gdm" user to have
> access on-the-fly when the GDM GUI is started.
>
> However, I notice that when using ZFS on Indiana the above commands fail
> with the following error:
>
>File system doesn't support aclent_t style ACL's.
>See acl(5) for more information on ACL styles support by Solaris.
>
> What is the appropriate command to use with ZFS?
chmod
> If different commands are needed based on the file system type, then
> how can GDM determine which command to use.
Do both? :)
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] problem with zfs receive -i
On Sat, Aug 19, 2006 at 07:21:52PM -0700, Frank Cusack wrote: > On August 19, 2006 7:06:06 PM -0700 Matthew Ahrens <[EMAIL PROTECTED]> > wrote: > >My guess is that the filesystem is not mounted. It should be remounted > >after the 'zfs recv', but perhaps that is not happening correctly. You > >can see if it's mounted by running 'df' or 'zfs list -o name,mounted'. > > You are right, it's not mounted. > > >Did the 'zfs recv' print any error messages? > > nope. > > > Are you able to reproduce this behavior? > > easily. Hmm, I think there must be something special about your filesystems or configuration; I'm not able to reproduce it. One possible cause for trouble is if you are doing the 'zfs receive' into a filesystem which has descendent filesystems (eg, you are doing 'zfs recv pool/[EMAIL PROTECTED]' and pool/fs/child exists). This isn't handled correctly now, but you should get an error message in that case. (This will be fixed by some changes Noel is going to putback next week.) Could you send me the output of 'truss zfs recv ...', and 'zfs list' and 'zfs get -r all ' on both the source and destination systems? > ah ok. Note that if I do zfs send; zfs send -i on the "local side", then > do zfs list; zfs mount -a on the "remote side", I still show space used > in the @7.1 snapshot, even though I didn't touch anything. I guess mounting > accesses the mount point and updates the atime. Hmm, maybe. I'm not sure if that's exactly what's happening, because mounting and unmounting a filesystem doesn't seem to update the atime for me. Does the @7.1 snapshot show used space before you do the 'zfs mount -a'? > On the "local" side, how come after I take the 7.1 snapshot and then 'ls', > the 7.1 snapshot doesn't start using up space? Shouldn't my ls of the > mountpoint update the atime also? I believe what's happening here is that although we update the in-core atime, we sometimes defer pushing it to disk. You can force the atime to be pushed to disk by unmounting the filesystem. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] problem with zfs receive -i
On August 19, 2006 7:06:06 PM -0700 Matthew Ahrens <[EMAIL PROTECTED]> wrote: On Sat, Aug 19, 2006 at 06:31:47PM -0700, Frank Cusack wrote: But when I login to zone smb and cd to /share/tmp/.zfs I get 'no such file or directory'. This does exist for other filesystems like /zone/eng/.zfs. My guess is that the filesystem is not mounted. It should be remounted after the 'zfs recv', but perhaps that is not happening correctly. You can see if it's mounted by running 'df' or 'zfs list -o name,mounted'. You are right, it's not mounted. Did the 'zfs recv' print any error messages? nope. Are you able to reproduce this behavior? easily. 1. Is the need to reboot a bug? Certainly having the other snapshots go missing seems like a bug. Yes, it is a bug for the filesystem to not be remounted after the 'zfs recv'. FYI, you should be able to get it mounted again by running 'zfs mount -a', you don't have to reboot the entire zone. yay, that works. 2. Why does the 7.1 snapshot have the extra space? If the filesystem (export/zone/smb/share/tmp) is modified, then some of the data that it shared with the snapshot (@7.1) will not be shared any longer, so it will become unique to the snapshot and show up as "used" space. Even if you didn't explicitly change anything in the filesystem, with the default settings, simply reading files in the filesystem will cause their atimes to be modified. ah ok. Note that if I do zfs send; zfs send -i on the "local side", then do zfs list; zfs mount -a on the "remote side", I still show space used in the @7.1 snapshot, even though I didn't touch anything. I guess mounting accesses the mount point and updates the atime. On the "local" side, how come after I take the 7.1 snapshot and then 'ls', the 7.1 snapshot doesn't start using up space? Shouldn't my ls of the mountpoint update the atime also? -frank ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
