On Tuesday, December 22, 2020 4:54:34 PM EST Matthew Almond via devel wrote: > > I currently download once and upgrade three different systems by > > rsync-ing the cache. > > > > Do I understand that this will no longer be supported or work? > > That's an interesting question. Is sharing the cache directory from > a single host intended to be shared like this? I am guessing no, but > it may still be common. > > It should still work, with two caveats: > 1. The files in the cache will be bigger, so a simple rsync will > involve more I/O, and the destination filesystem will also need more > space and I/O time. > 2. The systems must be the same endianness (The transcoded format > doesn't bother with network order, because it's not intended to be > shared) > 3. The page size must be the same for reflinking to work: This is > actually worked out when the filesystem is created, and defaults to > the system page size, and if not the same as the current page size, > the filesystem isn't even guaranteed to mount (see --sectorsize > option in mkfs.btrfs man page). > > In reality you're quite unlikely to share packages unless the > architecture were the same, which would steer both endianness and > page size to the same value. That said, I'm aware that aarch64 can > be flexible in both ways. I'm covering my bases with my statement: I > have thought about it, and don't think I'm in any position to make > promises. > > For this proposal: we're talking about shipping the code that would > allow this to be turned on. We're not talking about enabling it by > default. We can't until we have good answers to questions like this. Understood. To be clear, all three systems are x86_64, identical endianness, architecture, and page size (as far as I know). Also, this isn't a big deal, really. I just wanted to reduce network bandwidth without operating a local mirror. _______________________ sudo rsync -a --password-file=/etc/rsync.password --delete rsync://rsync@vfr/dnf /var/cache/dnf;sudo dnf --enablerepo=updates-testing upgrade -- Garry T. Williams _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
