I'm trying to use zfs send/receive to replicate the root pool of a
system and I can't think of a way to stop the received copy attempting
to mount the filesystem over the root of the destination pool.
For example, if I try
zfs send rpool/ROOT/10...@thu | zfs receive -d backup
It fails with
c
On Thu, 21 May 2009, Ian Collins wrote:
I'm trying to use zfs send/receive to replicate the root pool of a system and
I can't think of a way to stop the received copy attempting to mount the
filesystem over the root of the destination pool.
If you're using build 107 or later, there's a hidden
Hi Ian,
This procedure identifies the zfs send/receive syntax:
http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#Complete_Solaris_ZFS_Root_Pool_Recovery
Cindy
Ian Collins wrote:
I'm trying to use zfs send/receive to replicate the root pool of a
system and I can't think
On Wed, May 20, 2009 at 9:35 AM, Paul B. Henson wrote:
> On Wed, 20 May 2009, Darren J Moffat wrote:
>
>> Why do you think there is no progress ?
>
> Sorry if that's a wrong assumption, but I posted questions regarding it to
> this list with no response from a Sun employee until yours, and the
> e
Jorgen Lundman wrote:
Oh I forgot the more important question.
Importing all the user quota settings; Currently as a long file of "zfs
set" commands, which is taking a really long time. For example,
yesterday's import is still running.
Are there bulk-import solutions? Like zfs set -f file.tx
I have OSol 2009.06 (b111a), and I'm not sure I'm getting this ZFS ACL
thing:
%whoami
abalfour
% ls -V file
--+ 1 abalfour root 1474560 May 11 18:43 file
owner@:-w--d--A-W-C--:---:deny
according to that ACL I shouldn't be able to write anything having to do
with
My smc is not working properly. all the functions fail with a "system
information is not able to connect to the server. Reason: VER_ERROR.
Verify that the server is running. If it is running try stopping and
restarting it" when I attempt a command. Enclosed is a screen shot of
some of the test comm
Drew Balfour wrote:
I have OSol 2009.06 (b111a), and I'm not sure I'm getting this ZFS ACL
thing:
%whoami
abalfour
% ls -V file
--+ 1 abalfour root 1474560 May 11 18:43 file
owner@:-w--d--A-W-C--:---:deny
according to that ACL I shouldn't be able to write anyt
Miles Nordin wrote:
"re" == Richard Elling writes:
re> Whoa.
re> The slog is a top-level vdev like the others. The current
re> situation is that loss of a top-level vdev results in a pool
re> that cannot be imported.
this taxonomy is wilfully ignorant of the tou
deleting the lu's via sbdadm solved this. still wondering if there is
some reliable way to figure out what is using the zvol, though =)
On Wed, May 20, 2009 at 6:32 PM, milosz wrote:
> -bash-3.2# zpool export exchbk
> cannot remove device links for 'exchbk/exchbk-2': dataset is busy
>
> this is
Well, it worked for me, at least. Note that this is a very limited recovery
case- it only works if you have the GUID of the slog device from
zpool.cache, which in the case of a fail-on-export and reimport might not be
available. The original author of the fix seems to imply that you can use
any siz
abalf...@gmail.com wrote:
On May 21, 2009 11:08am, Mark Shellenbaum wrote:
> Nope, the owner always has the ability to fix broken permissions on
files. Otherwise the owner would be locked out of their own files.
Nuts; That's what I was trying to do; lock owners into read/write
without bei
> "re" == Richard Elling writes:
> "es" == Eric Schrock writes:
re> Another way to look at this, there is no explicit flag set in
re> the pool that indicates whether the slog is empty or
re> full.
Not that it makes a huge difference to me, but Eric seemed to say that
actuall
Here is the short story about of my Live Upgrade problem. This is not
the first time I am doing , but my previous attempts did not give me any
trouble of falling back to previous versions. I am not sure if it is
long gap between versions I am trying to upgrade or not. Today I tried
LU from s
On Thu, 21 May 2009, Miles Nordin wrote:
Anyway, Richard I think your whole argument is ridiculous: you're
acting like losing 30 seconds of data and losing the entire pool are
equivalent. Who is this line of reasoning supposed to serve? From
here it looks like everyone loses the further you ad
Miles Nordin wrote:
"re" == Richard Elling writes:
"es" == Eric Schrock writes:
re> Another way to look at this, there is no explicit flag set in
re> the pool that indicates whether the slog is empty or
re> full.
Not that it makes a huge difference to me, but Eric se
On May 21, 2009 11:08am, Mark Shellenbaum wrote:
Nope, the owner always has the ability to fix broken permissions on
files. Otherwise the owner would be locked out of their own files.
Nuts; That's what I was trying to do; lock owners into read/write without
being able to delete.
Thanks f
Mark J Musante wrote:
On Thu, 21 May 2009, Ian Collins wrote:
I'm trying to use zfs send/receive to replicate the root pool of a
system and I can't think of a way to stop the received copy
attempting to mount the filesystem over the root of the destination
pool.
If you're using build 107 or
On Thu, 21 May 2009, Peter Woodman wrote:
> Well, it worked for me, at least. Note that this is a very limited
> recovery case- it only works if you have the GUID of the slog device from
> zpool.cache, which in the case of a fail-on-export and reimport might not
> be available. The original author
To finally close my quest. I tested "zfs send" in osol-b114 version:
received 82.3GB stream in 1195 seconds (70.5MB/sec)
Yeeaahh!
That makes it completely usable! Just need to change our support
contract to allow us to run b114 and we're set! :)
Thanks,
Lund
Jorgen Lundman wrote:
We f
On Thu, 21 May 2009, Bob Friesenhahn wrote:
> For some people losing 30 seconds of data and losing the entire pool
> could be equivalent. In fact, it could be a billion dollar error.
I don't think anybody's saying to just ignore a missing slog and continue
on like nothing's wrong. Let the pool f
On Thu, May 21, 2009 at 10:17 PM, Jorgen Lundman wrote:
>
> To finally close my quest. I tested "zfs send" in osol-b114 version:
>
> received 82.3GB stream in 1195 seconds (70.5MB/sec)
>
> Yeeaahh!
>
> That makes it completely usable! Just need to change our support contract to
> allow us to run b
On Wed, May 20, 2009 at 12:06:49AM +0300, Ahmed Kamal wrote:
>Is anyone even using ZFS under Xen in production in some form. If so,
> what's
>your impression of reliability ?
Hmm, somebody needs to out itself. Short answer: yes.
Details:
Well, i've installed an IntelServer (2x QuadCore E
On Thu, May 21, 2009 at 02:51:53PM -0700, Nandini Mocherla wrote:
> Here is the short story about of my Live Upgrade problem. This is not
...
> # mount -F zfs /dev/dsk/c1t2d0s0 /mnt
> cannot open '/dev/dsk/c1t2d0s0': invalid dataset name
Have seen this when LUing from b110 to b114 on a V240 (we
24 matches
Mail list logo
