Date: Thu, 29 Dec 2016 11:44:20 +0100 From: "O. Hartmann" <ohartmann@walstatt.org> To: blubee blubeeme <gurenchan@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: A question about updating src & ports Message-ID: <20161229114408.4dfdbb8e@thor.walstatt.dynvpn.de> In-Reply-To: <CALM2mEm24Dx=HPfczjbhhVHo8Cok%2BrHAkRpihNbSEfJR_3P7vA@mail.gmail.com> References: <CALM2mEm24Dx=HPfczjbhhVHo8Cok%2BrHAkRpihNbSEfJR_3P7vA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Am Thu, 29 Dec 2016 18:11:38 +0800 blubee blubeeme <gurenchan@gmail.com> schrieb: > Howdy > > I went through the process of building world for the first time, that was > interesting but I got it. svn clean up prior object files, build world, > kernel, etc. > > Okay that part is fine > > I have a question about keeping ports up to date, in the past I did > portsnap fetch update to update the ports but since I totally deleted all > the ports and used svn checkout to get the latest ports. > > Can I mix portsnap fetch update or should I just continue to use svn update > /usr/ports > > Best, > Owen Well, from my own experience I left the path of "portsnap" and stay with svn alone. portsnap tends to "flood" the /var filesystem with a tremendous number of files over time. Each time you issue "portsnap fetch update", a file appears in /var/portsnap - it could be that the files appear in /var/db, I can't remember. Deleting them with "rm -rf *" leaves me then with an error from "rm": the argument line is to long due to the number of files. Therefore, I switched to svn. Well, svn itself is pumping up /usr/ports/.svn where it keeps all logs. Depending on the frequency of updates it grows. I do the same for /usr/src and by the time of fetching almost every day several times a day updates, the folder .svn is as large as /usr/src itself in its pristine state when fetched initially. For long-haul/long-running systems I'm concerned about the flood of data coming in and sometimes the filesystem is full. I avoid ZFS on build machines and use partitions for /usr/src, /usr/obj and sibblings which saved my ass several times for now. ZFS is a memory hog, on /usr/ports (which is on ZFS in mz scenario, the exclusion ...), a "svn update" can take up to 8 minutes on a 16GB, freshly rebooted box with a 3,4 Ghz XEON IvyBridge CPU and a ZFS RAIDZ with 4 HDDs and SSD for ZIL and L2ARC. On the other hand - I once tried to mix portsnap and svn and apart from any theory it worked a while and then it failed. That might be due to non-synchronisation between portsnap serving facilities and subversion repositories - which I would expect not to be in sync withing femto seconds. So it might be wise to saty with one specific method - I decided myself to keep it with svn. Just my experience, Kind regards, Oliver -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWGTpBAAKCRDS528fyFhY lJD2Af9qQT0HO++SSYqGi0OuQxo3UWzS1VY/71Yx9ANGpuGVac/OcUMh4jnLcgj8 CnePpshRGJb7/+I4J3slshL7LogLAgCS4LLEf73aafUw5a2IxUn+fzVIkdlorwQ1 NMWF7rFbq57kdCQNs4xWrtiqHgGs7+HccTYzbVuUq/YHjm8vMuKc =kt5U -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161229114408.4dfdbb8e>