> We import the pool with the -R parameter, might that contribute to the
> problem? Perhaps a zfs mount -a bug in correspondence with the -R parameter?
This Bugreport seems to confirm this:
http://bugs.opensolaris.org/view_bug.do?bug_id=6612218
Note that the /zz directory mentioned in the bugrep
Martin,
i think we should continue offline. Anyway see my comments/answers inline.
Thanks,
Gonzalo.
-->
Martin Uhl wrote:
The dirs blocking the mount are created at import/mount time.
how you know that??
In the previous example I could reconstruct that using zfs mount. Just lo
>>The dirs blocking the mount are created at import/mount time.
>how you know that??
In the previous example I could reconstruct that using zfs mount. Just look at
the last post.
I doubt ZFS removes mount directories.
>If you're correct you should been able to reproduce
>the problem by doing a
>> Is there better solution to this problem, what if the machine crashes?
>>
>
> Crashes are abnormal conditions. If it crashes you should fix the problem to
> avoid future crashes and probably you will need to clear the pool dir
> hierarchy prior to import the pool.
Are you serious? I really hope
Hi,
Martin Uhl wrote:
> obviously that will fail.
So AFAIK those directories will be created on mount but not removed on unmount
Good point. I was not aware of this. Will check with engineering.
The problem is not that exporting will not remove dirs (which I doubt it should) but moun
> If you umount a ZFS FS that has some other FS's underneath it, then the
> mount points for the "child" FS needs to be created to have those
> mounted; that way if you don't export the pool the dirs won't be deleted
> and next time you import the pool the FS will fail to mount because your
> m
Hi,
Martin Uhl wrote:
We opened a Support Case (Case ID 71912304) which after some discussion came to the
"conclusion" that we should not use /etc/reboot for rebooting.
Yes. You are using "/etc/reboot" which is the same as calling
"/usr/sbin/halt":
% ls -l /etc/reboot
lrwxrwxrwx 1 ro
We are also running into this bug.
Our system is a Solaris 10u4
SunOS sunsystem9 5.10 Generic_127112-10 i86pc i386 i86pc
ZFS version 4
We opened a Support Case (Case ID 71912304) which after some discussion came to
the "conclusion" that we should not use /etc/reboot for rebooting.
This leads me
You might be running into 6827199 - zfs mount -a performs mounts in the wrong
order.
There is a workaround contained in the bug
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6827199)
--
This message posted from opensolaris.org
___
zfs-d
On Jul 21, 2009, at 10:14 AM, Andre Lue wrote:
Hi Ian,
Thanks for the the reply. I will check your recommendation when I
get a chance. However this happens on any zfs that have hierarchical
zfs filesystems. I noticed it started this problem since snv_114.
This same filesystem structure la
Hi Ian,
Thanks for the the reply. I will check your recommendation when I get a chance.
However this happens on any zfs that have hierarchical zfs filesystems. I
noticed it started this problem since snv_114. This same filesystem structure
last worked fine with snv_110.
--
This message posted
On Tue 21/07/09 03:13 , "Andre Lue" no-re...@opensolaris.org sent:
> I have noticed this in snv_114 now at 117.
>
> I have the following filesystems.
> fs was created using zfs create pool/fs
> movies created using zfs create pool/fs/movies
> pool/fs/movies
> pool/fs/music
> pool/fs/photos
> pool/
I have noticed this in snv_114 now at 117.
I have the following filesystems.
fs was created using zfs create pool/fs
movies created using zfs create pool/fs/movies
pool/fs/movies
pool/fs/music
pool/fs/photos
pool/fs/archives
at boot /lib/svc/method/fs-local fails where zfs mount -a is called. fa
13 matches
Mail list logo
