2.2.0 more than one dataset to the same mountpoint
![Post Post](./styles/prosilver/imageset/icon_post_target.gif)
First, thanks a lot for your work ![Smile :-)](./images/smilies/icon_e_smile.gif)
I updatet my zfs 1.9.4 on ElCapitan 10.11 (Mac Mini 2009) to 2.2.0 and tested it relating to performance, reliability, handling, ... with an additional pool.
It seems very stable. No errors, no panic. Nice.
Sometimes the performance is 50% better than 1.9.4.
And it handles the memory more agil. Setting the primary cache to "all" leads to an increase of reserved memory. But this memory is given free again very fast when there is too much pressure on it. So that sometimes my system runs faster, more agil, and sometimes a little sluggish.
The variability of the performance can stem from lack of memory. My Mini '09 has only 2GB.
Installing and testing for usability, stability and reliability took me 4 days and now I am in "allday" mode. For a week or so I will use my system with 2.2.0 without thinking about it to get a feeling of how it behaves.
Everything works fine. Doesn't it?
There is one glitch in the matrix I discovered.
I copied the Music folder from my hfs backup to the zfs 2.2.0 pool on a different hdd ("zfs").
Than I wanted to test if I did the backup right and imported the old 1.9.4 pool ("zfs-extern"). There are all datasets set readonly for safety.
I forgot that I already mounted the Music dataset on 2.2.0 into my homefolder and that the one on the 1.9.4 pool has the same mountpoint.
"No problem, zfs gets it and refuses to mount it." No. It mounted it into the same mountpoint.
First I thought that it might be cause of mounting a 1.9.4 dataset to the same position as a 2.2.0.
I made a second 2.2.0 dataset ("zfs2") on the same 2.2.0 pool with the same mountpoint. No. Both mounted into the same position.
Maybe it is cause the Music folder is "different" cause it is shown in the finder with the german term ("Musik"). No.
Ok, trying another non apple dataset ("Tango"). No.
Nothing stopped 2.2.0 from mounting one dataset over the other into the same mountpoint.
In the end it looked like this:
The content of the last mounted dataset is shown at the common mountpoint.
When I unmount that dataset the contents of another dataset is shown.
Sometimes unmounting one dataset unmounts only this one and other times it pulls another dataset into unmounting, too.
It is not critical. Cause there is no data lost.
I set 'canmount=noauto' of zfs-extern/arne/Music so that it is not mounted when I import the old 1.9.4 pool. (The other Music datasets were just for testing.)
![Smile :-)](./images/smilies/icon_e_smile.gif)
I updatet my zfs 1.9.4 on ElCapitan 10.11 (Mac Mini 2009) to 2.2.0 and tested it relating to performance, reliability, handling, ... with an additional pool.
It seems very stable. No errors, no panic. Nice.
Sometimes the performance is 50% better than 1.9.4.
And it handles the memory more agil. Setting the primary cache to "all" leads to an increase of reserved memory. But this memory is given free again very fast when there is too much pressure on it. So that sometimes my system runs faster, more agil, and sometimes a little sluggish.
The variability of the performance can stem from lack of memory. My Mini '09 has only 2GB.
Installing and testing for usability, stability and reliability took me 4 days and now I am in "allday" mode. For a week or so I will use my system with 2.2.0 without thinking about it to get a feeling of how it behaves.
Everything works fine. Doesn't it?
There is one glitch in the matrix I discovered.
I copied the Music folder from my hfs backup to the zfs 2.2.0 pool on a different hdd ("zfs").
Than I wanted to test if I did the backup right and imported the old 1.9.4 pool ("zfs-extern"). There are all datasets set readonly for safety.
I forgot that I already mounted the Music dataset on 2.2.0 into my homefolder and that the one on the 1.9.4 pool has the same mountpoint.
"No problem, zfs gets it and refuses to mount it." No. It mounted it into the same mountpoint.
First I thought that it might be cause of mounting a 1.9.4 dataset to the same position as a 2.2.0.
I made a second 2.2.0 dataset ("zfs2") on the same 2.2.0 pool with the same mountpoint. No. Both mounted into the same position.
Maybe it is cause the Music folder is "different" cause it is shown in the finder with the german term ("Musik"). No.
Ok, trying another non apple dataset ("Tango"). No.
Nothing stopped 2.2.0 from mounting one dataset over the other into the same mountpoint.
In the end it looked like this:
- Code: Select all
$ zfs get mounted,mountpoint zfs/Music zfs2/Music zfs2/Music2 zfs-extern/arne/Music zfs2/Tango zfs-extern/arne/Tango
NAME PROPERTY VALUE SOURCE
zfs-extern/arne/Music mounted yes -
zfs-extern/arne/Music mountpoint /Users/arne/Music inherited from zfs-extern/arne
zfs/Music mounted yes -
zfs/Music mountpoint /Users/arne/Music local
zfs2/Music mounted yes -
zfs2/Music mountpoint /Users/arne/Music local
zfs2/Music2 mounted yes -
zfs2/Music2 mountpoint /Users/arne/Music local
zfs-extern/arne/Tango mounted yes -
zfs-extern/arne/Tango mountpoint /Users/arne/Tango inherited from zfs-extern/arne
zfs2/Tango mounted yes -
zfs2/Tango mountpoint /Users/arne/Tango local
The content of the last mounted dataset is shown at the common mountpoint.
When I unmount that dataset the contents of another dataset is shown.
Sometimes unmounting one dataset unmounts only this one and other times it pulls another dataset into unmounting, too.
It is not critical. Cause there is no data lost.
I set 'canmount=noauto' of zfs-extern/arne/Music so that it is not mounted when I import the old 1.9.4 pool. (The other Music datasets were just for testing.)