Re: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 20:41, Larry Rosenman wrote: > On 12/15/17, 1:28 PM, "owner-freebsd-curr...@freebsd.org" > wrote: > > > Wolfram Schneider writes: > > > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > > is now 11GB huge: > > > > FreeBSD 12-current > > $ du -hs /usr/obj > > 11G /usr/obj > > > > on FreeBSD 11-stable it was less the size: > > $ du -hs /usr/obj > > 5.6G /usr/obj > > Mine - also 12-current - reports 7.6G. > May we see your kernel config file, src.conf, and make.conf? I'm running a fresh installed FreeBSD without modifications. There is no src.conf or make.conf on the machine. -Wolfram -- Wolfram Schneider https://wolfram.schneider.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 20:20, Wolfram Schneider wrote: > On 15 December 2017 at 19:39, Konstantin Belousov wrote: >> On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: >>> On 15 December 2017 at 17:51, Wolfram Schneider wrote: >>> > On 15 December 2017 at 13:02, David Wolfskill >>> > wrote: >>> >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >>> >>> Hi, >>> >>> >>> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >>> >>> is now 11GB huge: >>> >>> >>> >>> FreeBSD 12-current >>> >>> $ du -hs /usr/obj >>> >>> 11G /usr/obj >>> >>> >>> >>> on FreeBSD 11-stable it was less the size: >>> >>> $ du -hs /usr/obj >>> >>> 5.6G /usr/obj >>> >>> >>> >>> this is a problem when you have a small VM with 20GB disk space or less. >>> >>> >>> >>> Is there a way to use less /usr/obj disk space during build? I know >>> >>> that we have to do some bootstrapping for newer compiler tools, but >>> >>> does we need to keep all temp files during the build? >>> >> >>> >> There was a change near the beginning of November; please see UPDATING >>> >> entry 20171101 -- you probably have several no-longer-used >>> >> subdirectories under /usr/obj/usr/src/. >>> >> >>> >> Once those are cleared out, my experience (tracking stable/11 & head in >>> >> different slices on the same machines) is that stbale/11 is using about >>> >> 5.0G, while head uses about 6.1G. >>> > >>> > I think the suspect directories are "tmp" and "obj-lib32", together >>> > they are 4.1GB huge. >>> > >>> > I will run a build of current again with a clean obj tree (-current on >>> > a recent -current). Let's see. >>> >>> I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov >>> 5) with an empty obj directory. >>> >>> `make buildworld' creates 9.7GB of obj data. After running `make >>> buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my >>> original report was on UFS) >> >> Most likely reason of the bump is generation of debugging data, turned on >> for 12. Another not usable thing to disable are tests and profile libraries. >> Put the following into /etc/src.conf: >> WITHOUT_PROFILE=yes >> WITHOUT_DEBUG_FILES=yes >> WITHOUT_TESTS=yes > > Hi Konstantin, > > I tried these 3 variables and the results looks much better, down to > 5.1GB from 12GB. Many thanks! > > $ du -hs obj* > 12G obj-debug > 5.1G obj-nodebug I did another test which of the WITHOUT_* variables saves most of the space 5.5G obj-WITHOUT_DEBUG_FILES (6.5GB less) 10G obj-WITHOUT_LIB32 (2GB less) 11G obj-WITHOUT_PROFILE (1GB less) 12G obj-WITHOUT_TESTS if you are short on disk space (e.g. a small VM with SSD drive), you should compile with $ export WITHOUT_DEBUG_FILES=YES; make buildworld -Wolfram -- Wolfram Schneider https://wolfram.schneider.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPTZFSBOOT in Current r326622 has problems - FIXED
On 12/15/17 18:37, Warner Losh wrote: > > I believe that these issues have been corrected in r326888. My > refactoring to make it easier to bring in the lua boot loader in r326593 > (after breaking the build in r326584 accidentally) uncovered some latent > subtle ordering issues. This cause GELI-enabled (but not even using) ZFS > boot loaders to fail. This was related to an odd interaction between zfs > and geli implementation files in gptzfsboot (and zfsboot) which caused > us to have two different implementations of malloc, with all the fun > you'd expect when the second one got called. > > If you have issues after r326888, please let me know. > Warner & Group I updated my system this morning to r326897 and can confirm that this problem has been solved. Good work Warner! Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/)
I got a "swap_pager: indefinite wait buffer" notice and looked
it up. (This was on a rpi2 booted (kernel and world) from a
USB SSD, swap partition in use instead of a swap file. It
was building devel/cmake via poudriere-devel .)
https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffer
reads like it is for page-out to disk:
QUOTE
5.9.
What does the error swap_pager: indefinite wait buffer: mean?
This means that a process is trying to page memory to disk, and the page
attempt has hung trying to access the disk for more than 20 seconds. It might
be caused by bad blocks on the disk drive, disk wiring, cables, or any other
disk I/O-related hardware. If the drive itself is bad, disk errors will appear
in /var/log/messages and in the output of dmesg. Otherwise, check the cables
and connections.
ENDQUOTE
But the code containing the message is for "swread":
(head -r326888)
# grep -r "indefinite wait buffer" /usr/src/sys/ | more
/usr/src/sys/vm/swap_pager.c:"swap_pager: indefinite wait buffer: bufobj: %p,
blkno: %jd, size: %ld\n",
Looking there. . .
static int
swap_pager_getpages(vm_object_t object, vm_page_t *m, int count, int *rbehind,
int *rahead)
{
. . .
VM_OBJECT_WLOCK(object);
while ((m[0]->oflags & VPO_SWAPINPROG) != 0) {
m[0]->oflags |= VPO_SWAPSLEEP;
VM_CNT_INC(v_intrans);
if (VM_OBJECT_SLEEP(object, &object->paging_in_progress, PSWP,
"swread", hz * 20)) {
printf(
"swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n",
bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount);
}
}
. . .
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/)
On 2017-Dec-16, at 8:23 PM, Eitan Adler wrote: > On 16 December 2017 at 10:47, Mark Millard wrote: >> I got a "swap_pager: indefinite wait buffer" notice and looked >> it up. (This was on a rpi2 booted (kernel and world) from a >> USB SSD, swap partition in use instead of a swap file. It >> was building devel/cmake via poudriere-devel .) >> >> https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffer >> reads like it is for page-out to disk: >> >> >> QUOTE >> 5.9. >> >> What does the error swap_pager: indefinite wait buffer: mean? >> >> This means that a process is trying to page memory to disk, and the page >> attempt has hung trying to access the disk for more than 20 seconds. It >> might be caused by bad blocks on the disk drive, disk wiring, cables, or any >> other disk I/O-related hardware. If the drive itself is bad, disk errors >> will appear in /var/log/messages and in the output of dmesg. Otherwise, >> check the cables and connections. >> ENDQUOTE >> >> >> But the code containing the message is for "swread": >> (head -r326888) > > If I understand correctly this is fixed by change "trying to page to" > to "trying to page from" ? In other words this happens on swap-in, > not swap-out. That is my understanding of what I reported. Side note comparing with rpi2 (armv7, cortex-A7): A rpi3 (aarch64, cortex-A53) got a couple of the messages during a build of the same port: devel/cmake . In this case it is emmc attached to the microsd-card slot via an adapter, instead of a USB SSD stick. === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/)
On 16 December 2017 at 10:47, Mark Millard wrote: > I got a "swap_pager: indefinite wait buffer" notice and looked > it up. (This was on a rpi2 booted (kernel and world) from a > USB SSD, swap partition in use instead of a swap file. It > was building devel/cmake via poudriere-devel .) > > https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffer > reads like it is for page-out to disk: > > > QUOTE > 5.9. > > What does the error swap_pager: indefinite wait buffer: mean? > > This means that a process is trying to page memory to disk, and the page > attempt has hung trying to access the disk for more than 20 seconds. It might > be caused by bad blocks on the disk drive, disk wiring, cables, or any other > disk I/O-related hardware. If the drive itself is bad, disk errors will > appear in /var/log/messages and in the output of dmesg. Otherwise, check the > cables and connections. > ENDQUOTE > > > But the code containing the message is for "swread": > (head -r326888) If I understand correctly this is fixed by change "trying to page to" to "trying to page from" ? In other words this happens on swap-in, not swap-out. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
need help using ng_patch to modify src/dst packets or alternative way
hi,
Can you help in my situation? My goal is so Box in my lan 10.1.1.2 to talk
to 10.1.1.1 and actually it would be talking to X.X.X.X outside ip using
one of my public IPs say 1.1.1.1.
I'm trying to modify packets to passthrough to a local IP.
I have a box that a specific IP is routed to it.. say 1.1.1.1
in my bce0 i don't have that ip configured but i have my public IP that say
2.2.2.2 that 1.1.1.1 is routed to it.
i configured 10.1.1.1/24 in bce0, my target box is 10.1.1.2/24.
i tried the following inside ngctl:
mkpeer ipfw: patch 300 in
name ipfw:300 src_dst_chg
msg src_dst_chg: setconfig { count=2 csum_flags=1 ops=[ { mode=1
value=0x0a010101 length=4 offset=3 } { mode=1 value=0x0a010102 length=4
offset=4 } ] }
in my box(10.1.1.1) i did:
sysctl net.inet.ip.fw.one_pass=0
/sbin/ipfw add 50 netgraph 300 ip from any to any to 1.1.1.1
then i do simple ping from outside box
i see the packets arrive on my 160 rule
but never leaves the box..
I would at least see packeta flow one direction to 10.1.1.2 and then that
need another ipfw and netgraph opposite rule.
If you have alternative way I'm happy to try...
Help much appreciated...
Sami
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
