But everything I've read says you can not export an NFS imported filesystem, unless using cachefilesd changes the rules. Since there is a new build package every night, rsync ends up copying the entire package every night. Even though rsync compresses the data, since a large part of the data is already compressed, the rsync compression is of little effect. Not sure what git would buy us. The issue is that this build package will have a considerable amount of data that may or may not be used. For example, the installer contains files for 3 different platforms, and if the developers or QA are not working on that platform that day, there would be no need to download that 1 Gb of data. Since the platform files are somewhat buried in the build package, I'd rather not have the end users "pick and choose" what they want downloaded (been there, done that, spent hours debugging the fact that they forgot to download a file). I've looked at mcachefs (a bit buggy and not been supported for several years) and now cachefilesd. Cachefilesd seems to work all except the problem of re-exporting the file systems. If not cachefilesd, anyone have any other suggestions on setting up what would probably be called a CDN? --- Wayne Johnson, | There are two kinds of people: Those 3943 Penn Ave. N. | who say to God, "Thy will be done," Minneapolis, MN 55412-1908 | and those to whom God says, "All right, (612) 522-7003 | then, have it your way." --C.S. Lewis >________________________________ > From: Alan Brown <a.brown@xxxxxxxxx> >To: linux-cachefs@xxxxxxxxxx >Sent: Monday, July 22, 2013 6:58 AM >Subject: Re: Using cachefs to distribute build output across a WAN > > >On 20/07/13 17:00, linux-cachefs-request@xxxxxxxxxx wrote: > >> 1. Using cachefs to distribute build output across a WAN >> (Wayne Johnson) > >> I'm a build master at my company.? As part of my responsibilities, I have an automated job that builds our entire product every night, packages the install image and a considerable amount of debug and support information into a single directory (a build package).? This is then rsync'ed to several remote sites for use by our developers. > >Rsync shouldn't consume great amounts of data unless you're changing everything, every night. > >For what you're describing a git type of environment is probably a better fit. > >> Any suggestions on how to provide a cache for folks using NFS (short of giving them each their own caches). > >Setup a NFS client on the remote site and then re-export what it's mounting to the local network. > >That will aggregate requests at cost of a little bit of latency (probably less than the WAN latency) > > > >-- >Linux-cachefs mailing list >Linux-cachefs@xxxxxxxxxx >https://www.redhat.com/mailman/listinfo/linux-cachefs > > > -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
