Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-27 Thread Coalson, Timothy Scott (S)
Let me rephrase: the main difference between a zfs fs and an ordinary folder is 
that you can create snapshots of a zfs fs, but not of a folder.  Your plans 
involve creating several zfs fs'es, but it isn't clear to me why you seem to 
want to do that rather than use ordinary folders.  The symlink way (for a 
non-zfs setup) would go something like:

# mount  /mnt/drive2
# mkdir /mnt/drive2/usr/local/src
# ln -s /mnt/drive2/usr/local/src /usr/local/src
# mkdir /usr/local/src/git

One new fs, on one mountpoint, that isn't mounted within the /usr tree.  
Though, in your case, you seem to be relocating the entirety of /usr/local onto 
a different pool, which would go slightly differently if it isn't currently 
empty.

Tim


From: Harry Putnam 
Sent: Tuesday, October 27, 2020 5:30 PM
To: openindiana-discuss@openindiana.org 
Subject: Re: [OpenIndiana-discuss] Layout of zfs fs

"Coalson, Timothy Scott (S)"  writes:

> 
> From: Harry Putnam 
> Sent: Sunday, October 25, 2020 4:29 PM
> To: openindiana-discuss@openindiana.org 
> Subject: [OpenIndiana-discuss] Layout of zfs fs
>
> ...
> In my case, running ubuntu 20:10 /usr is also zfs and part of rpool.
> ...
>
> (sorry for any formatting stupidity)
> Wait, are you sharing /usr across ubuntu and openindiana?  I hope not...

Sorry, my bad.  I am running as stated, but I am actually testing a
long running Openindian on hardware and A VBox vm of openindiana on a
windows host.   The last two are where I was and am testing

> Personally, I would use symlinks instead of making your mountpoint
> situation complicated.  If you don't need to separately snapshot or
> send each subfolder, I don't know what advantage there is to making
> more fs'es.

sorry for confusing things with info about ubuntu,

Here is the cited case from my msg you are responding to:

>> So should I create the zfs fs  by
>> zfs create ... -o mountpoint=/usr/local p0/local
>> zfs create ... p0/local/src
>> zfs create ... p0/local/src/git

>> (the -p option may be useful above.. I just want it
>> to be clear what is being done)

>> ending with /usr/local/src/git
>>
>> OR like this:

>> zfs create ... -o mountpoint=/usr/local p0/local
>> zfs create ... -o mountpoint=/usr/local/src  p0/src
>> zfs create ... -o mountpoint=/usr/local/src/git  p0/git

>> Again ending with  /usr/local/src/git

>> Is one way easier to manage or maintain?

You may note that exactly the same number of fs are created either
way. Not sure where symlinks would be especially useful.

But its also likely that I'm off in left field somwhere.


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-27 Thread Harry Putnam
v...@bb-c.de (Volker A. Brandt) writes:

> Hi Harry!
>
>
>> > Both will work.  Any dataset snapshot can be sent/received separately,
>> > if you want.  But you can also use a recursive send where the dataset
>> > itself and all "child datasets" will be included in the stream.  Check
>> > out the "-r" and "-R" flags in the zfs(1M) man page.
>>
>> I could not find an -r (lowercase) for send sub-command (maybe you are
>> only refering to zfs main cmd).
>
> No, it was a Solaris-ism that doesn't exist in illumos.  Sorry for not
> having checked it before sending the mail.
>
>> But experimenting with send -R I seem to have
>> gotten myself into some trouble.
>>
>> I attempted to:
>>zfs send -R rpool/export/home/MYUSER |ssh oi0 zfs recv p12x
>
> OK, so you are transferring an entire dataset, not a snapshot.  Not
> sure how this could have worked, as the -R flag only applies to
> snapshots, not datasets.

More sloppy work on my part, I actually did send a snapshot just
shorted the info in my post.

[...] Snipped the result of my misleading information 

But the good thing is that even after being totally mislead by me you
still managed to solve my issue.
>
>   zfs send -R rpool/export/home/MYUSER@now |
>   ssh oi0 zfs recv -e -o mountpoint=/export/home/MYUSER p12x/export/home
>
> You could leave out -R since there is nothing to replicate if you only
> have one dataset with one snapshot.
>
> The "-e" will tell zfs recv to just use the MYUSER part of the sent
> dataset name.  Note that p12x/export/home must already exist.
>
> If you want to be sure everything is copied before mounting it, use
> "zfs recv -u ..." so that datasets aren't automatically mounted on the
> receiving side.
>
>
> Hope this helps -- Volker

Very much so.  And thanks for being persistent even in the face of my
sloppy, mis-managed plea for help.


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-27 Thread Harry Putnam
"Coalson, Timothy Scott (S)"  writes:

> 
> From: Harry Putnam 
> Sent: Sunday, October 25, 2020 4:29 PM
> To: openindiana-discuss@openindiana.org 
> Subject: [OpenIndiana-discuss] Layout of zfs fs
>
> ...
> In my case, running ubuntu 20:10 /usr is also zfs and part of rpool.
> ...
>
> (sorry for any formatting stupidity)
> Wait, are you sharing /usr across ubuntu and openindiana?  I hope not...

Sorry, my bad.  I am running as stated, but I am actually testing a
long running Openindian on hardware and A VBox vm of openindiana on a
windows host.   The last two are where I was and am testing

> Personally, I would use symlinks instead of making your mountpoint
> situation complicated.  If you don't need to separately snapshot or
> send each subfolder, I don't know what advantage there is to making
> more fs'es.

sorry for confusing things with info about ubuntu,

Here is the cited case from my msg you are responding to:

>> So should I create the zfs fs  by
>> zfs create ... -o mountpoint=/usr/local p0/local
>> zfs create ... p0/local/src
>> zfs create ... p0/local/src/git
 
>> (the -p option may be useful above.. I just want it
>> to be clear what is being done)
  
>> ending with /usr/local/src/git
>> 
>> OR like this:
 
>> zfs create ... -o mountpoint=/usr/local p0/local
>> zfs create ... -o mountpoint=/usr/local/src  p0/src
>> zfs create ... -o mountpoint=/usr/local/src/git  p0/git
 
>> Again ending with  /usr/local/src/git

>> Is one way easier to manage or maintain?

You may note that exactly the same number of fs are created either
way. Not sure where symlinks would be especially useful.

But its also likely that I'm off in left field somwhere.


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-27 Thread Volker A. Brandt
Hi Harry!


> > Both will work.  Any dataset snapshot can be sent/received separately,
> > if you want.  But you can also use a recursive send where the dataset
> > itself and all "child datasets" will be included in the stream.  Check
> > out the "-r" and "-R" flags in the zfs(1M) man page.
>
> I could not find an -r (lowercase) for send sub-command (maybe you are
> only refering to zfs main cmd).

No, it was a Solaris-ism that doesn't exist in illumos.  Sorry for not
having checked it before sending the mail.

> But experimenting with send -R I seem to have
> gotten myself into some trouble.
>
> I attempted to:
>zfs send -R rpool/export/home/MYUSER |ssh oi0 zfs recv p12x

OK, so you are transferring an entire dataset, not a snapshot.  Not
sure how this could have worked, as the -R flag only applies to
snapshots, not datasets.

> So the result was that rpool/export/home/MYUSER showed up on the VBox
> instance of oi as p12x/export/home/MYUSER.   But it attempted to
> retain the mountpoint from the sending os of /export/home/reader.

Works as designed. The -R flag implies -p, which retains all properties
including the mountpoint.  I doubt it has worked in your case since
there is no -R flag for datasets.

> Fortunately the mount was unsucessful since MYUSER was not empty.

As it would be whenever a mountpoint isn't empty.

> So the sent fs is setting there and can cbe displayed with
> zfs list -r and shows the mountpoint that was refused as if it worked.

Well, it did work, it just didn't mount the dataset.

> On receiving OS:
>
> ,
> |  root # zfs list -r p12x
> |  NAME   USED  AVAIL  REFER  MOUNTPOINT
> |  p12x  3.86G   203G  3.86G  /export/home/reader
> |
> |  (Shows the data occupying 3.86 of space)
> `

Are you sure this is correct?  I don't see your dataset "p12x/export
/home/MYUSER" there.  You only have the pool itself, with the mount-
point property.

> However the fs p12x/export/home/MYSUSER will not accept substitute
> mount point and claims the fs does not exist:
>
> ,
> |   On the recv OS:
> |   I created an empty directory at /2x-rpool and tried:
> | (2x is hostname of sending OS)
> |  zfs set mountpoint=/2x-rpool p12x/export/home/reader
> |   cannot open 'p12x/export/home/reader': dataset does not exist
> `

That's because it really doesn't exist (see above).

> So I can't remount it. Or see the data in anyway I can think off.
>
> zfs cannot even destroy it:
>
> ,
> |   On recv OS:
> | root # zfs destroy -r p12x/export/home/reader
> |   cannot open 'p12x/export/home/reader': dataset does not exist
> `

Same here: It doesn't exist.

> Fortunately `zpool' still knew how:
>
> ,
> |   On recv OS:
> |zpool destroy p12x
> |(Finished with no errors)
> `
>
>zfs list -r shows it gone
>
>
> So is there a way to send rpool to a remote host without all that mess?

Yes, there is.  First, create a snapshot, like

  rpool/export/home/MYUSER@now

To change a mountpoint while receiving, specify it on the "receive"
side of the pipe (really only one line):

  zfs send -R rpool/export/home/MYUSER@now |
  ssh oi0 zfs recv -e -o mountpoint=/export/home/MYUSER p12x/export/home

You could leave out -R since there is nothing to replicate if you only
have one dataset with one snapshot.

The "-e" will tell zfs recv to just use the MYUSER part of the sent
dataset name.  Note that p12x/export/home must already exist.

If you want to be sure everything is copied before mounting it, use
"zfs recv -u ..." so that datasets aren't automatically mounted on the
receiving side.


Hope this helps -- Volker
-- 

Volker A. BrandtConsulting and Support for Solaris-based Systems
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-27 Thread Harry Putnam
v...@bb-c.de (Volker A. Brandt) writes:

> Harry Putnam writes:
>> >> So should I create the zfs fs  by
>> >> zfs create ... -o mountpoint=/usr/local p0/local
>> >> zfs create ... p0/local/src
>> >> zfs create ... p0/local/src/git
>> >>
>> >> (the -p option may be useful above.. I just want it
>> >> to be clear what is being done)
>> >>
>> >> ending with /usr/local/src/git
>> >>
>> >> OR like this:
>> >>
>> >> zfs create ... -o mountpoint=/usr/local p0/local
>> >> zfs create ... -o mountpoint=/usr/local/src  p0/src
>> >> zfs create ... -o mountpoint=/usr/local/src/git  p0/git
>> >
>> > Certainly the former.  If you use the second version, all three moint-
>> > points will be "local".  In the first version, the second (src) and
>> > third mountpoints will be "inherited".
>> >
>> > So if you one day decide that you have seen the light and want to con-
>> > vert to The One True local Mountpoint as Our Lord Intended It, you can
>> > just change the first mount point to /opt/local, and the rest will
>> > automatically inherit the new setting.
>>
>> Thanks for your thoughts.
>>
>> Sounds like the inherited mount point rates pretty high in your notion
>> of what works best.
>>
>> I suspect you have other reasons as well, and I would like to hear
>> about them if you don't mind expounding a bit more.
>>
>> For example:
>> What baring[sp] would either way have on the ability to `send/receive'?
>>
>> I'm very inexperienced in send/receive:
>>
>> In the method you prefer, and the first on shown in OP, can $USER
>> `send/receive' the whole of `local/src/git' in one move?  Or would it
>> need to be broken down into three send/receive sessions?
>
> Both will work.  Any dataset snapshot can be sent/received separately,
> if you want.  But you can also use a recursive send where the dataset
> itself and all "child datasets" will be included in the stream.  Check
> out the "-r" and "-R" flags in the zfs(1M) man page.

I could not find an -r (lowercase) for send sub-command (maybe you are
only refering to zfs main cmd).  But experimenting with send -R I seem to have
gotten myself into some trouble.

I attempted to:
   zfs send -R rpool/export/home/MYUSER |ssh oi0 zfs recv p12x

where rpool is from  oi installed on hardware, and oi0 is oi running
on vbox vm on windows.  And p12x is a new pool on the vbox vm created
for this experimentation.

So the result was that rpool/export/home/MYUSER showed up on the VBox
instance of oi as p12x/export/home/MYUSER.   But it attempted to
retain the mountpoint from the sending os of /export/home/reader.
Fortunately the mount was unsucessful since MYUSER was not empty.

So the sent fs is setting there and can cbe displayed with
zfs list -r and shows the mountpoint that was refused as if it worked.

On receiving OS:

,
|  root # zfs list -r p12x
|  NAME   USED  AVAIL  REFER  MOUNTPOINT
|  p12x  3.86G   203G  3.86G  /export/home/reader
| 
|  (Shows the data occupying 3.86 of space)
`

However the fs p12x/export/home/MYSUSER will not accept substitute
mount point and claims the fs does not exist:

,
|   On the recv OS:
|   I created an empty directory at /2x-rpool and tried:
| (2x is hostname of sending OS) 
|  zfs set mountpoint=/2x-rpool p12x/export/home/reader
|   cannot open 'p12x/export/home/reader': dataset does not exist
`

So I can't remount it. Or see the data in anyway I can think off.

zfs cannot even destroy it:

,
|   On recv OS:
| root # zfs destroy -r p12x/export/home/reader
|   cannot open 'p12x/export/home/reader': dataset does not exist
`

Fortunately `zpool' still knew how:

,
|   On recv OS:
|zpool destroy p12x
|(Finished with no errors)
`

   zfs list -r shows it gone


So is there a way to send rpool to a remote host without all that mess?
   


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-26 Thread Coalson, Timothy Scott (S)

From: Harry Putnam 
Sent: Sunday, October 25, 2020 4:29 PM
To: openindiana-discuss@openindiana.org 
Subject: [OpenIndiana-discuss] Layout of zfs fs

...
In my case, running ubuntu 20:10 /usr is also zfs and part of rpool.
...

(sorry for any formatting stupidity)
Wait, are you sharing /usr across ubuntu and openindiana?  I hope not...

Personally, I would use symlinks instead of making your mountpoint situation 
complicated.  If you don't need to separately snapshot or send each subfolder, 
I don't know what advantage there is to making more fs'es.

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-26 Thread Volker A. Brandt
Harry Putnam writes:
> >> So should I create the zfs fs  by
> >> zfs create ... -o mountpoint=/usr/local p0/local
> >> zfs create ... p0/local/src
> >> zfs create ... p0/local/src/git
> >>
> >> (the -p option may be useful above.. I just want it
> >> to be clear what is being done)
> >>
> >> ending with /usr/local/src/git
> >>
> >> OR like this:
> >>
> >> zfs create ... -o mountpoint=/usr/local p0/local
> >> zfs create ... -o mountpoint=/usr/local/src  p0/src
> >> zfs create ... -o mountpoint=/usr/local/src/git  p0/git
> >
> > Certainly the former.  If you use the second version, all three moint-
> > points will be "local".  In the first version, the second (src) and
> > third mountpoints will be "inherited".
> >
> > So if you one day decide that you have seen the light and want to con-
> > vert to The One True local Mountpoint as Our Lord Intended It, you can
> > just change the first mount point to /opt/local, and the rest will
> > automatically inherit the new setting.
>
> Thanks for your thoughts.
>
> Sounds like the inherited mount point rates pretty high in your notion
> of what works best.
>
> I suspect you have other reasons as well, and I would like to hear
> about them if you don't mind expounding a bit more.
>
> For example:
> What baring[sp] would either way have on the ability to `send/receive'?
>
> I'm very inexperienced in send/receive:
>
> In the method you prefer, and the first on shown in OP, can $USER
> `send/receive' the whole of `local/src/git' in one move?  Or would it
> need to be broken down into three send/receive sessions?

Both will work.  Any dataset snapshot can be sent/received separately,
if you want.  But you can also use a recursive send where the dataset
itself and all "child datasets" will be included in the stream.  Check
out the "-r" and "-R" flags in the zfs(1M) man page.


Regards -- Volker
-- 

Volker A. BrandtConsulting and Support for Solaris-based Systems
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-25 Thread Harry Putnam
v...@bb-c.de (Volker A. Brandt) writes:


[...]

>> So should I create the zfs fs  by
>> zfs create ... -o mountpoint=/usr/local p0/local
>> zfs create ... p0/local/src
>> zfs create ... p0/local/src/git
>>
>> (the -p option may be useful above.. I just want it
>> to be clear what is being done)
>>
>> ending with /usr/local/src/git
>>
>> OR like this:
>>
>> zfs create ... -o mountpoint=/usr/local p0/local
>> zfs create ... -o mountpoint=/usr/local/src  p0/src
>> zfs create ... -o mountpoint=/usr/local/src/git  p0/git
>
> Certainly the former.  If you use the second version, all three moint-
> points will be "local".  In the first version, the second (src) and
> third mountpoints will be "inherited".
>
> So if you one day decide that you have seen the light and want to con-
> vert to The One True local Mountpoint as Our Lord Intended It, you can
> just change the first mount point to /opt/local, and the rest will
> automatically inherit the new setting.

Thanks for your thoughts.

Sounds like the inherited mount point rates pretty high in your notion
of what works best.

I suspect you have other reasons as well, and I would like to hear
about them if you don't mind expounding a bit more.

For example:
What baring[sp] would either way have on the ability to `send/receive'?

I'm very inexperienced in send/receive:

In the method you prefer, and the first on shown in OP, can $USER
`send/receive' the whole of `local/src/git' in one move?  Or would it
need to be broken down into three send/receive sessions?


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Layout of zfs fs

2020-10-25 Thread Volker A. Brandt
Hi Harry!


> So should I create the zfs fs  by
> zfs create ... -o mountpoint=/usr/local p0/local
> zfs create ... p0/local/src
> zfs create ... p0/local/src/git
>
> (the -p option may be useful above.. I just want it
> to be clear what is being done)
>
> ending with /usr/local/src/git
>
> OR like this:
>
> zfs create ... -o mountpoint=/usr/local p0/local
> zfs create ... -o mountpoint=/usr/local/src  p0/src
> zfs create ... -o mountpoint=/usr/local/src/git  p0/git

Certainly the former.  If you use the second version, all three moint-
points will be "local".  In the first version, the second (src) and
third mountpoints will be "inherited".

So if you one day decide that you have seen the light and want to con-
vert to The One True local Mountpoint as Our Lord Intended It, you can
just change the first mount point to /opt/local, and the rest will
automatically inherit the new setting.


Cheers -- Volker
-- 

Volker A. BrandtConsulting and Support for Solaris-based Systems
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss