Re: src: continued use of Subversion for getting updates

On Sat, Jan 2, 2021, 10:07 PM Theron wrote: > On 1/3/21 12:02 AM, Theron wrote: > > On 12/23/20 3:49 AM, Warner Losh wrote: > >> I'm all ears on ways to make the docs better > > I think a heads-up on the Git move and how to stay up to date in > > /usr/src/UPDATING is needed. I was surprised to f

Re: src: continued use of Subversion for getting updates

On 1/3/21 12:02 AM, Theron wrote: On 12/23/20 3:49 AM, Warner Losh wrote: I'm all ears on ways to make the docs better I think a heads-up on the Git move and how to stay up to date in /usr/src/UPDATING is needed.  I was surprised to find no mention there. Oops, I did mean to say "UPDATING in

Re: src: continued use of Subversion for getting updates

On 12/23/20 3:49 AM, Warner Losh wrote: I'm all ears on ways to make the docs better I think a heads-up on the Git move and how to stay up to date in /usr/src/UPDATING is needed.  I was surprised to find no mention there. ___ freebsd-current@freebsd.o

Re: src: continued use of Subversion for getting updates

On Sat, Jan 2, 2021, 9:50 PM Theron wrote: > On 12/23/20 2:01 AM, Warner Losh wrote: > > On Tue, Dec 22, 2020, 11:47 PM Graham Perrin > wrote: > > > >> On 23/12/2020 00:10, Paul Mather wrote: > >>> … continue to get src updates via Subversion. … > >> As far as I can tell: > >> > >> * for stable/

Re: src: continued use of Subversion for getting updates

On 12/23/20 2:01 AM, Warner Losh wrote: On Tue, Dec 22, 2020, 11:47 PM Graham Perrin wrote: On 23/12/2020 00:10, Paul Mather wrote: … continue to get src updates via Subversion. … As far as I can tell: * for stable/12 alone stable/11 as well as the releng branches for as long as the proje

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

>> Though it can help attribute that to a source, Meaning to source 'account', vs say weak old CVSROOT that any could text edit on 200 account box, claim bitrot, etc. Whether inspiration came from the pet dog's bug report is moot, more secure systems narrow into accounts that would then be examine

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

LGTM! This patch also fixes another problem: the previous version of cp, when copying a large sparse file on UFS, would create some UFS indirect blocks (because it would keep truncating the file to larger sizes). The output file would still be sparse, but it would take up more space than the orig

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

The attached small patch seems to fix the problem. My hunch is that, for a large non-sparse file, SEEK_DATA SEEK_HOLE takes a fairly long time. These are done for each copy_file_range(2) syscall. cp was doing lots of them because of the small len argument. Bumping the len up to SSIZE_MAX results i

Re: Problem compiling git from ports

On 01.01.2021 21:19, Filippo Moretti wrote: It worked thank youFilippo On Friday, January 1, 2021, 5:25:10 PM GMT+1, Milan Obuch wrote: On Fri, 1 Jan 2021 16:11:52 + (UTC), Filippo Moretti wrote: I run again portmaster and I have the same error as previously reportedF

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

El día sábado, enero 02, 2021 a las 11:29:36a. m. -0700, Alan Somers escribió: > > El día sábado, enero 02, 2021 a las 05:06:05p. m. +, Rick Macklem > > escribió: > > > > > Just fyi, I've reproduced the problem. > > > All I did was create a 20Gbyte file > > > on UFS on a slow (4Gbyte or RAM, >

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

grarpamp writes: > > No amount of cryptography can or will protect against that. > > Though it can help attribute that to a source, No. You would end up with the committer saying "it came in as a bug-report, I looked at it, and it looked sensible so I committed it." Unless you are goin

Re: Finding a commit in cgit, given output from uname -a

On 02/01/2021 18:53, Michael Gmelin wrote: On 2. Jan 2021, at 19:44, Graham Perrin wrote: FreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 main-c530-g8b4c3a03f: Fri Jan 1 15:27:15 GMT 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEB

Re: Finding a commit in cgit, given output from uname -a

> On 2. Jan 2021, at 19:44, Graham Perrin wrote: > > FreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > main-c530-g8b4c3a03f: Fri Jan 1 15:27:15 GMT 2021 > root@mowa219-gjp4-8570p:/usr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > >

Finding a commit in cgit, given output from uname -a

FreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 main-c530-g8b4c3a03f: Fri Jan  1 15:27:15 GMT 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 finds nothing. Am I missi

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

On Sat, Jan 2, 2021 at 11:28 AM Matthias Apitz wrote: > El día sábado, enero 02, 2021 a las 05:06:05p. m. +, Rick Macklem > escribió: > > > Just fyi, I've reproduced the problem. > > All I did was create a 20Gbyte file > > on UFS on a slow (4Gbyte or RAM, > > slow spinning disk) laptop. > > (

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

El día sábado, enero 02, 2021 a las 05:06:05p. m. +, Rick Macklem escribió: > Just fyi, I've reproduced the problem. > All I did was create a 20Gbyte file > on UFS on a slow (4Gbyte or RAM, > slow spinning disk) laptop. > (The UFS file system is just what the installer creates these days.) >

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On 02/01/2021 16:48, Warner Losh wrote: On Sat, Jan 2, 2021 at 1:31 AM Graham Perrin > wrote: On 01/01/2021 19:24, Herbert J. Skuhra wrote: > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: >> At what should have been the end of my first up

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

t; > > > 2048 4194304 2 ssdrootfs (2.0G) > > > > 4196352 4194304 3 ssdvarfs (2.0G) > > > > 839065616777216 4 ssdswap (8.0G) > > > > 25167872 975046656 5 ssdusrfs (465G) > > > > 1000214528

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

t; > 839065616777216 4 ssdswap (8.0G) > > > 25167872 975046656 5 ssdusrfs (465G) > > > 1000214528 648- free - (324K) > > > > > > # mount -t ufs > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > >

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On Sat, Jan 2, 2021 at 8:43 AM Graham Perrin wrote: > On 02/01/2021 08:47, Herbert J. Skuhra wrote: > > >> < > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html> > >> still describes use of `svnlite` (not `git` or `got`) and, I guess, > >> might continue to do so for some

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On Sat, Jan 2, 2021 at 1:31 AM Graham Perrin wrote: > On 01/01/2021 19:24, Herbert J. Skuhra wrote: > > > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: > >> At what should have been the end of my first upgrade since the > >> transition to git: > >> > >> cd /usr/src/freebsd-current && m

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On Sat, 02 Jan 2021 17:18:10 +0100, Graham Perrin wrote: > > Sorry for the mis-formatting and lost line breaks in my previous > e-mail. Blame Thunderbird. > > As reference: > > > > /usr/src > > > BSD, third-party, and/or local source f

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

648 - free - (324K) > > > > > > # mount -t ufs > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > > >

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

Sorry for the mis-formatting and lost line breaks in my previous e-mail. Blame Thunderbird. As reference: /usr/src > BSD, third-party, and/or local source files ___ freebsd-current@freebsd.

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

25167872 975046656 5 ssdusrfs (465G) > > 1000214528 648- free - (324K) > > > > # mount -t ufs > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > /dev/gpt/ssdusrfs on /

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

On Sat, Jan 2, 2021 at 9:02 AM Matthias Apitz wrote: > El día sábado, enero 02, 2021 a las 08:42:01a. m. -0700, Alan Somers > escribió: > > > > # dd if=guru-20210102.tar.gz > of=/mnt/AcerC720/backups/guru-20210102.tar.gz > > > bs=8m > > > 460

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

El día sábado, enero 02, 2021 a las 08:42:01a. m. -0700, Alan Somers escribió: > > # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz > > bs=8m > > 4601+1 records in > > 4601+1 records out > > 38603862368 bytes transferred in 506.778929 secs

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On Sat, Jan 02, 2021 at 03:43:04PM +, Graham Perrin wrote: > ... > >> In this context, is `cd /usr/src` still true? > > If you clone the repository to /usr/src instead of e.g. > > /usr/src/freebsd-current. > > Thanks again. > > I imagine that use cases will _eventually_ include trios of direc

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On 02/01/2021 08:47, Herbert J. Skuhra wrote: still describes use of `svnlite` (not `git` or `got`) and, I guess, might continue to do so for some time. In this context, is `cd /usr/src` still true? If you clone the re

Re: cp(1) of large files is causing 100% CPU utilization and poor transfer

> I copy often large backup files to an external USB disk and hit the > following problem since updating to r368166: > > A transfer with dd(1) works fast and as expected (~70M / sec): > > # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz > bs=8m > 4601+1

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Folks, please change the Subject: line here. This has now become a thread of only tangiental interest to a typical FreeBSD developer (in this case, typified by me :-) ) mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/l

cp(1) of large files is causing 100% CPU utilization and poor transfer

to r368166: A transfer with dd(1) works fast and as expected (~70M / sec): # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz bs=8m 4601+1 records in 4601+1 records out 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) # ls -lh guru-20210102.tar.gz -r

moving /usr/src and /usr/obj to another machine for installation

Hello, I have a potent machine where I build my systems and ports with poudriere: [root@jet /usr/src]# uname -a FreeBSD jet 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368166: Mon Nov 30 10:06:30 CET 2020 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 [root@jet /usr/src]# svn info Path

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On Sat, 02 Jan 2021 09:47:07 +0100 "Herbert J. Skuhra" wrote: > On Sat, 02 Jan 2021 09:31:36 +0100, Graham Perrin wrote: > > > > With the transition to Git > > > > == > > > > If it's true that /usr/src is _no longer_ a predictable path to the > > source files, then is i

Re: Terminal colours in current

> On 2. Jan 2021, at 07:25, Rozhuk Ivan wrote: > > Hi! > > I am tring current and found that kernel options: > options TERMINAL_NORM_ATTR = (FG_GREEN|BG_BLACK) # def to > SC_NORM_ATTR / 2 | 0x00 > options TERMINAL_KERN_ATTR = (FG_YELLOW|BG_BLACK) # def t

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

> No amount of cryptography can or will protect against that. Though it can help attribute that to a source, else ignore rainbow books and go back to telnet, root password 'root', CVS, no backups, logs, etc. > As interesting as this thread has been (not!) Contrare. Equally as interesting as thre

Re: etcupdate, svnlite, documentation etc. following the transition of source to Git

On Sat, 02 Jan 2021 09:31:36 +0100, Graham Perrin wrote: > > With the transition to Git > > == > > If it's true that /usr/src is _no longer_ a predictable path to the > source files, then is it still appropriate for users' fortunes to > include this FreeBSD tip? > >

etcupdate, svnlite, documentation etc. following the transition of source to Git

On 01/01/2021 19:24, Herbert J. Skuhra wrote: On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: At what should have been the end of my first upgrade since the transition to git: cd /usr/src/freebsd-current && make installworld && etcupdate 𠄴– concluded with a successful installworld, t