| View previous topic :: View next topic |
| Author |
Message |
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
 Posted: Sun Aug 07, 2016 3:48 am Post subject: latest zfs version |
 |
|
zfs-0.6.5.7 is the most recent stable version available upstream and in the portage. But zfs-0.6.5.7 is not keyworded for amd64 or ~amd64. Does anybody why that is? Is this not deemed stable? Is it really "hard-mask-unstable" bad? Why would upstream mark it stable then?
I would have thought it would be ~amd64. |
|
| Back to top |
|
 |
ryao
Retired Dev
Joined: 27 Feb 2012
Posts: 132
|
| Posted: Tue Aug 09, 2016 3:10 pm Post subject: Re: latest zfs version |
|
|
| devsk wrote: | zfs-0.6.5.7 is the most recent stable version available upstream and in the portage. But zfs-0.6.5.7 is not keyworded for amd64 or ~amd64. Does anybody why that is? Is this not deemed stable? Is it really "hard-mask-unstable" bad? Why would upstream mark it stable then?
I would have thought it would be ~amd64. |
The proposed stable API was merged into the packaging to try to prevent future changes from breaking the boot process on root pools. My initial attempts at updating it to 0.6.5.7 encountered a regression that I have not had time to run down. I am taking the convention of having -r0 be unpatched and -r1 be patched. To prevent breakage from going to the old API, I am not keywording -r0, but it is available for those who are aware of the risk of the unstable /dev/zfs API.
My time to work on this has been somewhat limited as I was worn out by a task at work (I am writing a compiler in the academic sense). Bringing this to completion has very recently become a priority at work, so this will be getting attention from me during my work hours soon. Also, I have a solution for the new userland (new API) and old kernel modules (old API) mismatch in development at work that will allow me to keyword the normal modules without risking that people encounter the mismatch issue. It involves a shim library that implements the new API using the legacy API and it is working in the lab, although the automatic fallback to the legacy API isn't working yet. This is in addition to fixing the regression that is blocking the update. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Tue Aug 09, 2016 4:00 pm Post subject: |
|
|
Thanks for the update! Appreciate your work in this area.
All my logic for mounting 'home' in the initrd is custom logic. I don't use the root pool. So, I should be good with the latest code. I will hard unmask the three packages and move on. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Wed Aug 10, 2016 3:31 am Post subject: |
|
|
Wow!! Something broken really bad between 0.6.5.4 and 0.6.5.7!
I have a mountpoint for myhome/vmware set to /vmware, "zfs mount -a" mounts it on /myhome/vmware, completely ignoring the mountpoint option.
If I 'zfs set' the mountpoint again to the same value as I get from 'zfs get', it correctly moves the mount to /vmware.
How did this break?
Is there a way for me to workaround this? I found this on one system, I don't want to go through the same process of setting mountpoint for every FS on my other, more complex system. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Sat Aug 13, 2016 6:15 am Post subject: |
|
|
anyone got any hints?
One other thing that's weird: After setting the mount point manually again (like zfs set using the value from zfs get), zfs list still shows the wrong mountpoints under MOUNTPOINT. So, zfs get shows /usr/portage while zfs list shows /myhome/portage, and the actual mount is now /usr/portage as per 'df' and /proc/mounts. WTH!! |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Tue Aug 16, 2016 2:31 am Post subject: |
|
|
Finally found the cause of the above anomaly. It was because I forgot to update the initrd... |
|
| Back to top |
|
|
|
Portage & Programming
