Re: CFT for vendor openzfs - week 5 reminder + memdisk images

On Tue, 4 Aug 2020 at 02:25, Matthew Macy <mmacy_at_freebsd.org> wrote:
>
> On Wednesday, July 8th I issued the initial call for testing for the
> update to HEAD to vendored openzfs. We'd like to give users roughly a
> month to test before merging.  The tentative merge date is August
> 17th.
>
> Again, I hope it's not terribly controversial to point out that
> it really rests with users of non amd64 platforms to test to avoid any
> unpleasant surprises the next time they update their trees following
> the merge.
>
> amd64, i386, and aarch64 memdisk images can be found at:
> https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/
>
> If you're using a platform not listed above and would be inclined to
> test if you had an image to work with, let us know. Alternatively, you
> can still build following the instructions below.
>
> The review for merging in to base can be found at:
> https://reviews.freebsd.org/D25872
>
> ==========================================================
> NB: Do NOT zpool upgrade unless you are willing to live without the
> ability to ever rollback to the legacy zfs kmod.
>
> Checkout updated HEAD:
> % git clone https://github.com/mattmacy/networking.git -b
> projects/openzfs_vendor freebsd
>
> Checkout updated openzfs in to sys/contrib:
> % git clone https://github.com/zfsonfreebsd/ZoF.git -b
> projects/openzfs_vendor freebsd/sys/contrib/openzfs
>
> Build world and kernel with whatever your usual configuration is.
> Where possible the openzfs kmod is backward compatible with the cmd
> utils in HEAD so common operations work with existing tools and the
> new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
> are backward compatible with the zfs kmod in HEAD. Although ideally
> one would test this in a separate boot environment, the
> interoperability should allow one to rollback without too much
> difficulty.
>
> NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools
> other than the root pool will not be imported at boot.
>
> Thanks in advance for your time.
>
> -M
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"


Hi. I have some problems downloading the amd64 image:

baymax /home/djn > fetch -a
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
freebsd-openzfs-amd64-2020081100-memstick.img. 19% of  655 MB 2179 kBps 04m07s
fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
truncated: 134152192/687158140 bytes
baymax /home/djn > fetch -ar
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  882 kBps 09m10s
fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
truncated: 139132928/687158140 bytes
baymax /home/djn > fetch -ar
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  647 kBps 12m23s
fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
truncated: 142065664/687158140 bytes
baymax /home/djn >

It also fails using Firefox on windows on a different machine. (It's
also much slower from that machine, about 200 kB/sec. I have no idea
if that's relevant.)

-- 
Daniel Nebdal