Re: buildworld + ccache trouble
On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok wrote: > Hello All! > I recently updated to r212634 and tried to build CURRENT tree with ccache. > > However, I got build error: > > > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Is it a know issue? > Any solutions? If I remember correctly, this happens when you try to build 32-bit library set on amd64 (you do not have WITHOUT_LIB32 set in /etc/src.conf). My solution was to disable 32-bit support by setting that option. If you're still using ccache version 2.4, try upgrading to 3.0.1, though I'm not sure if this problem has been fix. The only other alternative that I know of is to not use ccache to buildworld on amd64. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld + ccache trouble
On Mon, Sep 20, 2010 at 4:43 AM, Dmitry Krivenok wrote: > Your patch works fine for me, thanks! > However, I don't see any performance gain when using ccache: > > Number of cache hits is very low. > I need to understand this... Make sure you have the following environment variables set: CCACHE_HASH_COMPILER=1 (2.4) CCACHE_COMPILERCHECK=content (3.0+) CCache will not use cached files if the compiler has changed. The default way of detecting this change is by comparing compiler's size and modification time. Since the modification time changes after each installworld, you are effectively clearing the cache for all subsequent compilations. Setting the above variables will cause the "sameness" of the compiler to be determined by hashing its contents, which should only change if the compiler code was actually modified. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov wrote: > On 26 November 2011 11:44, Milan Obuch wrote: >> Hi, >> >> I am playing a bit with 9.0-PRERELEASE compiling it from source updated >> via csup. In both example files there is line specifying what to csup >> >> *default release=cvs tag=RELENG_8 >> >> which is incorrect, I think. It is convenient for me to issue just >> >> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >> to update full sources without need to create any cvsup config file, >> however in system installed from 9.0 snapshot (maybe two weeks old) >> this file points to version 8 files, so I need to correct it for >> 9.0-PRERELEASE to not accidentally download older version sources. >> >> The same is also true after upgrade from source - make installworld >> install example files pointing to older version... >> >> Is it something I do not know about or is it an oversight? I think this >> line should already be changed to new tag... >> >> *default release=cvs tag=RELENG_9 > > Hi. > > Fixed. Thanks for your report. > Now cvs tag points to RELENG_9 in 9.x sources. Should standard-supfile also be updated to point to RELENG_9_0? I'm using csup with "tag=RELENG_9_0" and standard-supfile still points to HEAD. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions
On Mon, Dec 5, 2011 at 11:47 AM, Poul-Henning Kamp wrote: > In message <201112051743.13483.mark.martinec+free...@ijs.si>, Mark Martinec > wri > tes: >>Using a guided partitioning install of 9.0-RC2 on a 64GB (virtual) disk >>(from a 9.0-RC2 ISO image) results in the following GPT partitioning: >> >># gpart show /dev/ada0 >>=> 34 134217661 ada0 GPT (64G) >> 34 128 1 freebsd-boot (64k) >> 162 125828992 2 freebsd-ufs (60G) >> 125829154 6709248 3 freebsd-swap (3.2G) >> 132538402 1679293 - free - (820M) >> >>This is most unfortunate for installations using 4kB sectored disks >>or SSD disks, [...] > > This is not a new problem, you face the same issue with RAID5 devices. > > > GEOM defines two provider properties for handling all these cases > correctly: stripesize + stripeoffset. > > If the disk-driver has a 4k drive, or suspects it has a 4k drive ( > these properties are advisory only), it should announce that with > the stripe* properties on its GEOM provider. > > GEOM classes are responsible for passing these properties up with > whatever adjustments are necessary (for instance modifying the > stripeoffset for partitions). > > The partitioning tools, (All of them!) should examine these two > properties and prod the user towards not doing something silly. Interesting... But I think 4k alignment by default would be a good thing even for 512 drives. First, because some 4k drives fake 512 byte sectors, and I'm not sure that the partitioning tools would be able to correctly detect this in all cases. Second, someone may want to copy the partition table and dump/restore data to another drive, which could be using 4k sectors. Same problem could arise if you're using some disk imaging software. Since the industry is heading in that direction, I think the safer thing to do is to set the minimum alignment to 4k and increase that when the underlying hardware (e.g. RAID) requests it. Personally, I partition my servers manually by creating a 512 kB boot partition aligned to 512 kB, and align all remaining partitions to 1 MB. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall guided partitioning should 4k-align swap and ufs partitions
On Mon, Dec 5, 2011 at 1:24 PM, Poul-Henning Kamp wrote: > In message > > , Maxim Khitrov writes: > >>Interesting... But [...] > > A "But" which I read to mean "Nahh, too hard, lets just hack it..." > > I don't agree with that, we should do it right. How do you get around the hardware claiming to use 512-byte sectors when it actually uses 4 kB internally? Same problem with virtual machines, as Curtis pointed out. IMHO, this is just a matter of using safe default values in bsdinstall. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SU+J systems do not fsck themselves
On Wed, Dec 28, 2011 at 11:42 AM, Matthias Andree wrote: > Am 27.12.2011 22:53, schrieb David Thiel: >> I've had multiple machines now (9.0-RC3, amd64, i386 and earlier >> 9-CURRENT on ppc) running SU+J that have had unexplained panics and >> crashes start happening relating to disk I/O. When I end up running a >> full fsck, it keeps turning out that the disk is dirty and corrupted, >> but no mechanism is in place with SU+J to detect and fix this. A bgfsck >> never happens, but a manual fsck in single-user does indeed fix the >> crashing and weird behavior. Others have tested their SU+J volumes and >> found them to have errors as well. This makes me super nervous. > > The one thing I figured is that in the light of power outages, or > crashing virtualization hosts, you really really really need to disable > disk write caches, and this affects softupdates, journalling, asynch > file systems, just about everything. > > The fact that makes matters worse is that journalling or softupdates > allow you to mount a silently-corrupted file system, whereas the > traditional UFS/UFS2 sync/asynch mounts will fsck themselves in the > foreground, so they get fixed before the FS panics. > > So can you be sure that: > > - your driver, chip set and hard disk execute ordered writes in order, > > - your driver, chip set and hard disk actually write data to permanent > storage BEFORE acknowledging a successful write? > > Whenever I fixed these issues, I had no more corruptions. > > For ata and sata, there are loader tunables you will want to set, > hw.ata.wc=0 and kern.cam.ada.write_cache=0. > > If your drives are under ada, ad, or ahci related control, try these > settings. For SCSI, use camcontrol to turn the write cache off. > softupdates is supposed to rectify most of the performance penalties > incurred. > > Note also that you needed to set ahci_load=YES and atapicam_load=YES in > 8.X, I've never bothered to check 7.X or 9.X WRT these settings. This is a bit off-topic, but I'm curious what the effect of NCQ is on softupdates? Since that too has the ability to reorder writes to disk, should it be disabled in addition to cache? Also, I would say that if you are using a hardware raid controller with a BBU, then allowing the use of controller's cache and write-back policy should be safe for use with softupdates. Any caching mechanism, for that matter, that has a separate power supply source should be ok. For example, the Intel 320 SSDs have a few on-board capacitors that are used to flush the cache in the event of a power loss. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrading FreeBSD to use the NEW pf syntax.
On Mon, Nov 26, 2012 at 10:00 AM, Gleb Smirnoff wrote: > Paul, > > On Sat, Nov 24, 2012 at 02:11:32PM -, Paul Webster wrote: > P> I only really need one question answered in honesty; > P> > P> I personally think that by forking our own version of PF we have > P> essentially made something totally different to what everyone wants to > P> use. Which is fine, but because of that development of new features have > P> dropped behind. > P> > P> If we had kept up with OpenBSD's version even if we trailed it by one > P> MAJOR release; at least part of the development would have been done. > P> > P> So now we end up in a situation where we have these firewalls, > P> IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf. > P> So timewise the fork of pf may have actually cost more in time rather than > P> less. > P> > P> I don't however think the 'solution' to the problem is just to say no to > P> the userbase by not even trying to port across the newer pf. I think we > P> should look at bringing it across, slowly and seeing what the uptake is > P> like; in a few MAJOR releases we can start to look at which of the > P> firewalls realistically are not used that much and should be deprecated. > > If you see a large userbase that eagers to see new pf, then you can port > it to FreeBSD, maintain it, catch up with new versions from OpenBSD, > and so on. No one forbids you doing that. Putting aside the issue of new syntax... What is the actual state of pf in the upcoming FreeBSD 9.1-RELEASE? Have there been any changes from 9.0? The most recent list of PRs doesn't look very encouraging. I'm setting up a new office firewall right now. I tried installing OpenBSD 5.2, but it doesn't recognize the Intel X25-E drive in AHCI mode or the Intel X540 10GbE adapter, which should be supported. Maybe I can fix these problems, but I'd much rather see an improvement in the state of FreeBSD firewalls. No one needs three choices, we need one that works and is actively maintained. - Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels wrote: > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: >> all of that is true, but you are missing the point. Having two versions of >> pf on the bsd's at the user level, is a bad thing. It confuses people, >> which puts them off. Its a classic case of divide an conquer for other >> platforms. I really like the idea of the openpf version, that has been >> mentioned in this thread. It would be awesome if it ended up as a supported >> linux thing as well, so the world could be rid of iptables. However i guess >> thats just an unrealistic dream > > And you don't seem to get the point that _someone_ has to do the work. > No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
