Sponsor Name: Reenigne Location: Niagara on the Lake, Ontario, Canada Bandwidth: 100 Mb/s Admin Contact: Matt Vandermeulen The mirror can be accessed via the following IP addresses: Hostname (v4/v6): mirror.reenigne.net IPv4: 199.66.254.92 IPv6: 2606:5480:1010:3:681c:26f7:b469:fee6 There is a limit on concurrent connections [amount/no]: Not currently Additional comments: - Web available HTTP/HTTPS https://mirror.reenigne.net/gentoo/ - Web portage, too https://mirror.reenigne.net/gentoo-portage/ - rsync at rsync://mirror.reenigne.net/gentoo-portage - Crons to sync portage at 10, and 40 past the hour - Distfiles update every 4 hours, at half past the hour - Server spawned 2015-04-20 with IPv4 only - IPv6 added today; looks to possibly be only IPv6 Canadian mirror, which is neat - Traffic snapshot of the last 7 days is low - https://reenigne.net/screenshots/1455324480.png - Canada, eh?
Currently in the process of moving the distfiles over to another instance under a public account - the IPv4 address will stay the same, but the IPv6 will be updated as follows: 2606:5480:1010:3:29e4:7b3a:4cd7:8e60 The rsync mirror is ready, distfiles might take another few hours to move.
Distfiles finished last night as well, all good to go.
We do not need additional mirrors in Europe at this time, thanks. -A
I think we should add it.
FWIW, the mirror is still going along with ZFS snapshots available. As mentioned in the original post, the mirror is in Canada, not Europe (though it has moved within Canada). There have been some changes since I submitted this in 2016, however, and I'll post the current status below: Sponsor Name: Reenigne Location: New Brunswick, Canada Bandwidth: 10 Gb/s Admin Contact: Matt Vandermeulen The mirror can be accessed via the following IP addresses: Hostname (v4/v6): mirror.reenigne.net IPv4: 172.83.105.10 IPv6: 2606:5480:1000::300:10 There is a limit on concurrent connections [amount/no]: Not currently Additional comments: - Web available HTTP/HTTPS https://mirror.reenigne.net/gentoo/ - Web portage, too https://mirror.reenigne.net/gentoo-portage/ - ZFS snapshots for distfiles going back to late 2014 https://mirror.reenigne.net/gentoo-snapshots/ - ZFS snapshots for portage going back about the same https://mirror.reenigne.net/gentoo-portage-snapshots/ - rsync at rsync://mirror.reenigne.net/gentoo-portage - Crons for portage sync: 15 */12 * * * - Crons for distfiles sync: 0 6 * * * - Server spawned 2015-04-20 with IPv4 only - IPv6 added in 2016; no longer the only IPv6 Canadian mirror, which is great progress! - Canada, eh?
sam: please add this mirror to the system! Matt Vandermeulen: Can you check if there is a subtle historical misconfig in your gentoo-snapshots targets? In the 2019-03-01-0213 and earlier snapshots, it's only the distfiles directories directly in the folder. I hope to use this as part of the new historical distfiles hosting project per bug 834712, because you've got a great collection of the 2014-present distfiles. Could you easily tweak those old snapshots to make them $SNAPSHOT/distfiles/, to be consistent?
Yup, this would have been a break between where I started sourcing my own, while the earlier dates came from elsewhere. I can reconcile this, but it will take time (a function of iops), as I'd likely rewrite the entire zfs snapshot history to look like it does today... which would help storage efficiency as well, but it's not quite 10TiB, so it's not a big deal. Would you prefer this done sooner (this month) or later (can this wait a month or two)? Feel free to reach out if you'd like some hosting (re: bug 834712) in a similar manner as these snapshots are. The storage for this mirror is backed by rbd, moving it to rgw would be fairly trivial (with all the usual large-object-count caveats that come with it).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/api.git/commit/?id=ca5e18cbfe9d21a9e2e6f9b295a8132671f69cbf commit ca5e18cbfe9d21a9e2e6f9b295a8132671f69cbf Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-06 06:43:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-06 06:43:15 +0000 mirrors/distfiles: add Reenigne Bug: https://bugs.gentoo.org/574590 Signed-off-by: Sam James <sam@gentoo.org> files/mirrors/distfiles.xml | 5 +++++ 1 file changed, 5 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/api.git/commit/?id=61884d5362926f2053442f15eae7e457ab138f55 commit 61884d5362926f2053442f15eae7e457ab138f55 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-06 07:06:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-06 07:06:01 +0000 mirrors/rsync: add Reenigne - rsync12.ca.gentoo.org Bug: https://bugs.gentoo.org/574590 Signed-off-by: Sam James <sam@gentoo.org> files/mirrors/rsync.xml | 4 ++++ 1 file changed, 4 insertions(+)
Matt, thank you very much! I've added your mirror to the distfiles mirror list, christened your mirror as rsync12.ca.gentoo.org, and included it in rsync.namerica.gentoo.org. (In reply to Matt Vandermeulen from comment #7) Robin, I assume you'll reach out?
Also, Matt, for the rsync mirror (gentoo-portage), please start pulling from our masterportage mirror. I've whitelisted your public IPv4 + IPv6. If I need to change that, let me know. https://wiki.gentoo.org/wiki/Project:Infrastructure/Mirrors/Rsync#Fetching_data
(In reply to Matt Vandermeulen from comment #7) > Yup, this would have been a break between where I started sourcing my own, > while the earlier dates came from elsewhere. I can reconcile this, but it > will take time (a function of iops), as I'd likely rewrite the entire zfs > snapshot history to look like it does today... which would help storage > efficiency as well, but it's not quite 10TiB, so it's not a big deal. > > Would you prefer this done sooner (this month) or later (can this wait a > month or two)? That's where the "easily" part of my questions come in. If it's not easy, don't worry, I'll do it when I fetch data in future. > Feel free to reach out if you'd like some hosting (re: bug 834712) in a > similar manner as these snapshots are. The storage for this mirror is > backed by rbd, moving it to rgw would be fairly trivial (with all the usual > large-object-count caveats that come with it). RGW/RBD/CephFS are NOT good candidates because they can't dedupe as well as ZFS et al, and the project for bug 834712 likely to have very high refcounts of duplicated files (it will cover nearly 25 years of distfiles). What *would* be really helpful is a way to query your mirror for a minimal fetch set; or MAYBE a zfs send of the snapshots that could be post-processed. We won't have the literal 600TB of raw space needed to process it without some deduplication. The 10TB deduped is probably what we can easily fit (esp. if the Council approves the 4x30TB QLC drives I'm asking for)
Sam, thanks! This is complete, and the first primary mirror sync snapshot is available at https://mirror.reenigne.net/gentoo-portage-snapshots/2024-01-06-1556/ Robin, it's trivial to do, just some data movement. I can try to whip something up this weekend, it'd be nice to gain some of that space back (zfs would have lost snapshot benefit around that time). Yeah, I think the only way to make RGW make sense there would be to have some indirection layer to uses content addressable storage in RGW, but that adds a layer of complexity. My current RBD-backed storage is ZFS on RBD, and I'd be happy to `zfs send` anything you'd like if you have a target. The only thing I don't love about the setup is that it's not redundant (though RBD snap/clones and some janky automation could make it so...). FWIW, the current sizing use on my mirror (before fixing the snapshot chain, and with my limited history) if it helps you size things: root@prod-mirror-001:~# zfs list -o name,used,refer | grep -E '^NAME|gentoo' NAME USED REFER data-nvme/gentoo-portage 169G 880M data/gentoo 9.78T 949G I'll mark this bug resolved, and add myself to the CC for #834712, feel free to ping me there (or here if still appropriate, of course) if I can assist.
