From owner-freebsd-hackers@freebsd.org Sun Jul 5 21:20:44 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E64AB98E61F; Sun, 5 Jul 2015 21:20:44 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FD8D1AF2; Sun, 5 Jul 2015 21:20:44 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by widjy10 with SMTP id jy10so145591299wid.1; Sun, 05 Jul 2015 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JZpUdox2plAAvEBjAn6ocQ2U9zwuPPgSzVxrDnQkoQU=; b=BUtFhIE1oRTQk9+hts99L7+z3//3NQxTBRXS4TQ8cT0V+gqaFoPPE2SClp3upxLZ9B PuuYMKs8ARhXbBJ61ZTA0pmg+xITJOOWK4LbIK0Lad4Ta08kbaQ+McTwengzR9/r/nfQ hEOvXly96+7YM3LFR3I9Hq9NGXkuL/e0YNgzzHaH63RnGuedW4oi06b/fCfc7zJ4knYr UBJwTNDNI7Fi4HvgA0145PeSVv9J3VUdiueavHRYD8rIupL8vEuN4UkULEuOsctmWUFy SKcpeW1qor0ZTkdm1XS44TYE8dfNbaZJjrqvqMukxvo+1JigjgPKfM3vs1VR4+LS5QbU Te+w== MIME-Version: 1.0 X-Received: by 10.180.78.136 with SMTP id b8mr81317494wix.44.1436131242776; Sun, 05 Jul 2015 14:20:42 -0700 (PDT) Received: by 10.194.64.102 with HTTP; Sun, 5 Jul 2015 14:20:42 -0700 (PDT) In-Reply-To: <20150704190016.GD97710@ivaldir.etoilebsd.net> References: <20150704184939.GC97710@ivaldir.etoilebsd.net> <20150704190016.GD97710@ivaldir.etoilebsd.net> Date: Mon, 6 Jul 2015 00:20:42 +0300 Message-ID: Subject: Re: UTF-8 xmonad (firefox+flash) crush Xorg From: Andrey Fesenko To: Baptiste Daroussin Cc: Adrian Chadd , "freebsd-hackers@freebsd.org" , freebsd-x11 Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 21:20:45 -0000 On Sat, Jul 4, 2015 at 10:00 PM, Baptiste Daroussin wrote: > On Sat, Jul 04, 2015 at 11:57:27AM -0700, Adrian Chadd wrote: >> Can't get it from the coredump? >> > Sure if he rebuilds firefox with symbols, hence why I said non trivial :) > > Best regards, > bapt Unfortunately, did not succeed to collect reproducible environment to debug. Many large packages (long assembly when changing options), many established dependencies (not clean environment, work laptop) But it seems figured out the conditions under which an error occurs, lang/ghc and */hs-* bee build with OPTIONS_FILE_SET+=LLVM (disabled for default port) after disable and rebuild all port, work stable. From owner-freebsd-hackers@freebsd.org Mon Jul 6 13:20:26 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0F239848 for ; Mon, 6 Jul 2015 13:20:26 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CB3C1620 for ; Mon, 6 Jul 2015 13:20:26 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by qkei195 with SMTP id i195so116563420qke.3 for ; Mon, 06 Jul 2015 06:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YHKCOfHTMeVPxdZg5WUh2e1NBeF64wulWRBtDmCWBws=; b=olohwz6mw3VoivPubBuw84Q3TZLCdtEHfC4VG7wqSOaoXDmkvCPrEDOxNgnPnFo4rY TtB5Ot1Cij8gt/HtRWWaSIsUmqTXUnkqvv8ljZdkK+CrrCoyYF3DbGN9PcrHpWCpza7g OODOh2coCFxZXtdFUKMvnXQgjUfGTzMlgqECrWo9/ZRryCE0XnEK0GWRblY7Ax3XdXru TSAam7E5/xEj+2DGZ+Y9xAGXxVyV5mI6zfugbtaRXyddF+lGPQC5RXhohAoi5mjJQhyo UrOIvHclRsJ3m3GcL4Iz6MAUktFv2+vF5BV56NiUAnj/ELSCLdG4+Z6QoRm+EiXoC7jx alfg== X-Received: by 10.140.202.65 with SMTP id x62mr75414828qha.102.1436188825449; Mon, 06 Jul 2015 06:20:25 -0700 (PDT) Received: from mbp.home (179-125-129-24.desktop.com.br. [179.125.129.24]) by mx.google.com with ESMTPSA id z81sm9241605qkg.44.2015.07.06.06.20.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 06:20:24 -0700 (PDT) Sender: Renato Botelho Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Subject: Re: rename() + fsync() implementation From: Renato Botelho In-Reply-To: <20150704133034.GA3102@dft-labs.eu> Date: Mon, 6 Jul 2015 10:20:21 -0300 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <4B5ABFF0-AAE5-4E74-BAD4-E7B301DC3F7D@FreeBSD.org> References: <2770DA5F-D7F2-46D9-9158-10C86115F8AC@FreeBSD.org> <20150704133034.GA3102@dft-labs.eu> To: Mateusz Guzik X-Mailer: Apple Mail (2.2102) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:20:26 -0000 > On Jul 4, 2015, at 10:30, Mateusz Guzik wrote: >=20 > On Fri, Jul 03, 2015 at 01:59:43PM -0300, Renato Botelho wrote: >> Some time ago we found a bug on pfSense and after investigating we = figured out the root cause was passwd / group related tools was not = checking if files were safe in disk, and system ended up with a 0 length = passwd/group db after a power cycle. There are more context at revision = [1]. >>=20 >> After that, bapt@ suggest to do similar fix for cap_mkdb and = services_mkdb, that also can be found at another review [2]. >>=20 >=20 > This definitely needs an explanation what is going on here. >=20 > When the problem from [1] is encountered, which file appears to be > zeroed? >=20 > If the new one, should not O_SYNC you added in several places take = care > of that? (btw, it would be nicer if that was fsynced before close > instead) According comment #11 of pfSense bug #4523 [3]: ---------- With SU, with or without J, you end up with 0 byte master.passwd, = passwd, group, pwd.db, spwd.db. Or some subset of those. Without SU, you = end up with master.passwd and/or group corrupted, containing parts of = other files in /etc/. It's replicable on stock FreeBSD 9.0 through 11-CURRENT by running the = following:=20 #!/bin/sh /usr/sbin/pw userdel -n 'admin' /usr/sbin/pw groupadd all -g 1998 /usr/sbin/pw groupadd admins -g 1999 /usr/sbin/pw groupmod all -g 1998 -M '' echo = \$6\$O/T6GYkcgYvOBTGm\$KvOh3zhFKiA6HMEPktuImAI8/cetwEFsgj7obXdeTcQvn6mhs50= HgkWt6nfnxNhTIb2w4Je6dqdKtARavxThP1 | /usr/sbin/pw usermod -q -n root -s = /bin/tcsh -H 0 echo = \$6\$O/T6GYkcgYvOBTGm\$KvOh3zhFKiA6HMEPktuImAI8/cetwEFsgj7obXdeTcQvn6mhs50= HgkWt6nfnxNhTIb2w4Je6dqdKtARavxThP1 | /usr/sbin/pw useradd -m -k = /etc/skel -o -q -u 0 -n admin -g wheel -s /bin/sh -d /root -c 'System = Administrator' -H 0 /usr/sbin/pw unlock admin -q /usr/sbin/pw groupmod all -g 1998 -M '0' /usr/sbin/pw groupmod admins -g 1999 -M '0' then power cycling the system. If using SU, you'll end up with 0 byte = files. Without SU, you'll have corrupted files containing parts of some = other file(s) in /etc. ---------- > If the old one, this still has the window (although miniscule compared > to 5 mins) since whatever crash/failure you experienced can happen > before you fsync. It may be ok enough in practice, but then the = question > is whether O_SYNC on the new file was of any significance. Or to state > differently, do callers have to fsync/O_SYNC the file they are passing > as an argument? >=20 > Of course it may be either one can appear truncated. The idea of using O_SYNC on temporary file, and call fsync() on = directory after rename came from Kirk McKusick: ---------- Applications that are properly written take these steps: 1. write new file to a temporary name. 2. fsync newly written file. 3. rename temporary name to file to be updated. 4. For faster results, fsync directory that has updated file to = commit the new file. ---------- I decided to change it on libutil because the functions are specific for = passwd and group operations, otherwise it would need to be changed on = all applications that calls it (usr.bin/chpass, usr.sbin/pw, = usr.sbin/rpc.yppasswdd). > Assuming the whole approach makes sense here are some comments about = the > code itself: >=20 >> /* >> * Make sure file is safe on disk. To improve performance we = will call >> * fsync() to the directory where file lies >> */ >> if (rename(tname, dbname) =3D=3D -1 || >> (dbname_dir =3D dirname(dbname)) =3D=3D NULL || >=20 > dirname returns a pointer to an internal buffer, so it is not suitable > for use in a library function (think: foo =3D dirname(...); = this(...);) What do you think about having dirname_r implemented? Using the same = approach we have today for basename/basename_r. > Since it can fail and does not depend on rename, it should have been > done earlier. >=20 > dbname_dir looks like a weird name. Something like dbdirname would be > better. OK >> (dbname_dir_fd =3D open(dbname_dir, O_RDONLY|O_DIRECTORY)) = =3D=3D -1 || >=20 > dbname_dir_fd is definitely bad. This is not a name, this is a fd. So > dbdirfd. OK >> fsync(dbname_dir_fd) !=3D 0) { >=20 > Why does this do '!=3D 0' instead of '=3D=3D -1=E2=80=99? No special reason, I=E2=80=99m going to change it. >> if (dbname_dir_fd !=3D -1) >> close(dbname_dir_fd); >> err(1, "Cannot rename `%s' to `%s'", tname, dbname); >=20 > It could be renamed succeeded, so this msg should be modified to state > what really failed. But as a library func it likely should return an > error instead, indicating which part failed. Agreed. >> } >>=20 >> if (dbname_dir_fd !=3D -1) >> close(dbname_dir_fd); >>=20 >=20 > At this point dbname_dir_fd is guaranteed to be !=3D -1. True, thanks for pointing this out. >> The idea is to implement a =E2=80=9Csync rename=E2=80=9D function to = do all these steps. I thought about it and IMO lib/libutil would be a = good place to implement it. But since I=E2=80=99m starting to touch src = now, I would like to hear more opinions about this. >>=20 >>=20 >> [1] https://reviews.freebsd.org/D2978 >> [2] https://reviews.freebsd.org/D2982 >=20 > --=20 > Mateusz Guzik [3] https://redmine.pfsense.org/issues/4523#note-11 -- Renato Botelho From owner-freebsd-hackers@freebsd.org Mon Jul 6 14:28:21 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E824CA78C for ; Mon, 6 Jul 2015 14:28:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery4.ore.mailhop.org (pmta2.delivery4.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id B549B1E48 for ; Mon, 6 Jul 2015 14:28:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 6 Jul 2015 14:28:12 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t66ESDcf032359; Mon, 6 Jul 2015 08:28:13 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1436192893.1334.27.camel@freebsd.org> Subject: Re: rename() + fsync() implementation From: Ian Lepore To: Renato Botelho Cc: Mateusz Guzik , FreeBSD Hackers Date: Mon, 06 Jul 2015 08:28:13 -0600 In-Reply-To: <4B5ABFF0-AAE5-4E74-BAD4-E7B301DC3F7D@FreeBSD.org> References: <2770DA5F-D7F2-46D9-9158-10C86115F8AC@FreeBSD.org> <20150704133034.GA3102@dft-labs.eu> <4B5ABFF0-AAE5-4E74-BAD4-E7B301DC3F7D@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:28:21 -0000 On Mon, 2015-07-06 at 10:20 -0300, Renato Botelho wrote: > > On Jul 4, 2015, at 10:30, Mateusz Guzik wrote: > > > > On Fri, Jul 03, 2015 at 01:59:43PM -0300, Renato Botelho wrote: > >> Some time ago we found a bug on pfSense and after investigating we figured out the root cause was passwd / group related tools was not checking if files were safe in disk, and system ended up with a 0 length passwd/group db after a power cycle. There are more context at revision [1]. > >> > >> After that, bapt@ suggest to do similar fix for cap_mkdb and services_mkdb, that also can be found at another review [2]. > >> > > > > This definitely needs an explanation what is going on here. > > > > When the problem from [1] is encountered, which file appears to be > > zeroed? > > > > If the new one, should not O_SYNC you added in several places take care > > of that? (btw, it would be nicer if that was fsynced before close > > instead) > > According comment #11 of pfSense bug #4523 [3]: > > ---------- > With SU, with or without J, you end up with 0 byte master.passwd, passwd, group, pwd.db, spwd.db. Or some subset of those. Without SU, you end up with master.passwd and/or group corrupted, containing parts of other files in /etc/. > > It's replicable on stock FreeBSD 9.0 through 11-CURRENT by running the following: > > #!/bin/sh > > /usr/sbin/pw userdel -n 'admin' > /usr/sbin/pw groupadd all -g 1998 > /usr/sbin/pw groupadd admins -g 1999 > /usr/sbin/pw groupmod all -g 1998 -M '' > echo \$6\$O/T6GYkcgYvOBTGm\$KvOh3zhFKiA6HMEPktuImAI8/cetwEFsgj7obXdeTcQvn6mhs50HgkWt6nfnxNhTIb2w4Je6dqdKtARavxThP1 | /usr/sbin/pw usermod -q -n root -s /bin/tcsh -H 0 > echo \$6\$O/T6GYkcgYvOBTGm\$KvOh3zhFKiA6HMEPktuImAI8/cetwEFsgj7obXdeTcQvn6mhs50HgkWt6nfnxNhTIb2w4Je6dqdKtARavxThP1 | /usr/sbin/pw useradd -m -k /etc/skel -o -q -u 0 -n admin -g wheel -s /bin/sh -d /root -c 'System Administrator' -H 0 > /usr/sbin/pw unlock admin -q > /usr/sbin/pw groupmod all -g 1998 -M '0' > /usr/sbin/pw groupmod admins -g 1999 -M '0' > > then power cycling the system. If using SU, you'll end up with 0 byte files. Without SU, you'll have corrupted files containing parts of some other file(s) in /etc. > ---------- > > > If the old one, this still has the window (although miniscule compared > > to 5 mins) since whatever crash/failure you experienced can happen > > before you fsync. It may be ok enough in practice, but then the question > > is whether O_SYNC on the new file was of any significance. Or to state > > differently, do callers have to fsync/O_SYNC the file they are passing > > as an argument? > > > > Of course it may be either one can appear truncated. > I can't quite unpack the wording of this, but it is necessary to fsync() the temp file before closing it (or maybe opening using O_SYNC is just as good, I've never tried that). Without the fsync, SU g'tees that the metadata is consistant but not necessarily the file's contents. Very often that metadata consistancy manifests as a file with no contents after an abrupt power cycle. > The idea of using O_SYNC on temporary file, and call fsync() on directory after rename came from Kirk McKusick: > > ---------- > Applications that are properly written take these steps: > > 1. write new file to a temporary name. > 2. fsync newly written file. > 3. rename temporary name to file to be updated. > 4. For faster results, fsync directory that has updated file to commit the new file. > ---------- > I can confirm based on years of embedded-systems experience that the scenarios you describe above do occur, and the solution you're proposing is basically the one I've used to fix the problem in the past. The one difference is that instead of opening the temp file O_SYNC I've used fsync() on it just before the close to ensure the contents reach the media. I've always wanted something like a rename_sync() syscall that makes stronger guarantees than the current rename(2) (which only promises that a file of that name will exist after the call, but not which of the two potential files it might be, and there are no promises about the file's contents). It seems like the system should be able to more-efficiently figure out what needs to be sync'd -- it should be able to sync the directories involved without needing to do string manipulations of pathnames and whatnot. Speaking of "the directories involved" if the rename operation moves the file within the hierarchy there are really two directories that would need to be fsync'd for a more general solution, right? > I decided to change it on libutil because the functions are specific for passwd and group operations, otherwise it would need to be changed on all applications that calls it (usr.bin/chpass, usr.sbin/pw, usr.sbin/rpc.yppasswdd). > > > Assuming the whole approach makes sense here are some comments about the > > code itself: > > > >> /* > >> * Make sure file is safe on disk. To improve performance we will call > >> * fsync() to the directory where file lies > >> */ > >> if (rename(tname, dbname) == -1 || > >> (dbname_dir = dirname(dbname)) == NULL || > > > > dirname returns a pointer to an internal buffer, so it is not suitable > > for use in a library function (think: foo = dirname(...); this(...);) > > What do you think about having dirname_r implemented? Using the same approach we have today for basename/basename_r. > That sounds like a good idea to me. > > [...] Unrelated to this proposed patch, but maybe useful information... some files are less critical than passwd/group but you'd still like to increase the chances that recent writes hit the media to protect against power loss. I've found that these values in /etc/sysctl.conf reduce the time that buffers linger in memory before being pushed out to devices: # Tune the flush time for pending disk writes. The syncer process flushes # dirty blocks from memory to disk after they've been in the queues for these # amounts of time. It is important that metadelay < dirdelay < filedelay. kern.metadelay=3 kern.dirdelay=4 kern.filedelay=5 While I can't quite remember the details, I do remember that these values are the smallest delays you can set and still have the system function correctly. (At least, that was true in the 8.x timeframe when I cooked up these tweaks.) On a sysytem that does a lot of IO, these parameters will be bad for IO throughput, they're purely for an embedded system that does relatively little IO and needs to increase the odds that things like log files get written without too much latency (so that the evidence needed to debug a crash gets preserved, for example). Afaik, these are system-wide parms and there's no way to set an equivelent per-filesystem tuning of them. -- Ian From owner-freebsd-hackers@freebsd.org Tue Jul 7 00:16:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79617995A3B for ; Tue, 7 Jul 2015 00:16:04 +0000 (UTC) (envelope-from analysiser@gmail.com) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42CE0192C for ; Tue, 7 Jul 2015 00:16:04 +0000 (UTC) (envelope-from analysiser@gmail.com) Received: by pdbep18 with SMTP id ep18so114375786pdb.1 for ; Mon, 06 Jul 2015 17:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=evuDVmR4M2IKMP2bFay7MEE6j51id8igjrAhnphdF4s=; b=Mc5oMrj1Atx0GwWEIXe/jy3r3tEm0IpPr2LpRTBv+p4OERH0dhXtIzPgQs//NXKba9 KNxrtNWFcXiK5oIiu7Coids5VXdhl4j8EcU5pSwhYAgT0S2yf/hiJ7tOn+rM09U9ulPl BB7fjrPA72GZchzsnu1KwK95ZJviMlp21b2ueWJo4FKdXKCzzdR10xwQk52rphQnn9f1 sGpRF/DeFwcOs/h2ZSwpXIlPTRtXDtnoN1Sf1v3mZs5AEq4fICb2FRGam54NE5qF5F9A SL2KbEMnnK01xm0SEnb+QqtuGJSA7KIhCVoE0BpEWtjRJX8kNIZQpXj2jh+rhzIXuPdW QjDA== X-Received: by 10.70.54.196 with SMTP id l4mr2836182pdp.2.1436228163768; Mon, 06 Jul 2015 17:16:03 -0700 (PDT) Received: from a45e60cc77bb.amazon.com (54-240-196-185.amazon.com. [54.240.196.185]) by mx.google.com with ESMTPSA id qg5sm19546403pbc.68.2015.07.06.17.16.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 17:16:02 -0700 (PDT) From: Analysiser Subject: tgptboot build failure: don't know how to make rijndael-alg-fst.o Message-Id: <484BE13F-ECD6-405B-A108-A3EEAD8793C0@gmail.com> Date: Mon, 6 Jul 2015 17:16:01 -0700 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:16:04 -0000 Hi, Recently I=E2=80=99ve been doing some research on trusted boot on = freebsd. I was following the instructions from: = https://lists.freebsd.org/pipermail/freebsd-hackers/2015-March/047376.html= = I=E2=80=99ve finished building world and building kernel, applied the = 0001-trusted-gptboot-preview.patch, and try to build tgptboot, where I = encountered the error message: make: don't know how to make rijndael-alg-fst.o. Stop I=E2=80=99ve been trying to redo the preparation a couple of times and = the error persist. May I ask for any clues about this? Thanks in = advance! I=E2=80=99ve been performing all operations on a freebsd and64 version = in virtual box. File system used is ZFS. # uname -a FreeBSD freebsd-vbox 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue = Nov 11 21:02:49 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 # svn update Updating '.': At revision 285223. Xiao Li From owner-freebsd-hackers@freebsd.org Tue Jul 7 09:19:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CC84ABA0 for ; Tue, 7 Jul 2015 09:19:46 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E159810D4 for ; Tue, 7 Jul 2015 09:19:45 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 39E202A1611 for ; Tue, 7 Jul 2015 11:14:36 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id AVfUHNmfA5Mt for ; Tue, 7 Jul 2015 11:14:35 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1B55A2A1962 for ; Tue, 7 Jul 2015 11:14:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jzrHXFRm-9iz for ; Tue, 7 Jul 2015 11:14:35 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id EBB152A1611 for ; Tue, 7 Jul 2015 11:14:34 +0200 (CEST) Message-ID: <559B985D.1070907@embedded-brains.de> Date: Tue, 07 Jul 2015 11:14:05 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: style(9) and header guards Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 09:19:46 -0000 Hello, it seems that the header guards, e.g. #ifndef _SYS_TYPES_H_ #define _SYS_TYPES_H_ ... #endif /* !_SYS_TYPES_H_ */ are not covered by the style(9) guide. Is this intentional? Would it be=20 possible to add something for it? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Tue Jul 7 10:10:21 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DCB098F778 for ; Tue, 7 Jul 2015 10:10:21 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EC671069 for ; Tue, 7 Jul 2015 10:10:21 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: by qgii30 with SMTP id i30so81698251qgi.1 for ; Tue, 07 Jul 2015 03:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FPP0BIWpmg5w5szR9FmQSQPOIAmGRH9Cn9hDiLGQzxc=; b=vTJU6zL4AeHnnTZHfK7sDibg4b71H4qCzus4raZbDf3zvvrmKn81XGEmRt0mZPT5AC TuINzrk6QkXH77+17usfjtgNfsuisLxYtN5ygkx6i+lfwPasglM+QMQ0wmfyGcXXEehH VAQyrMVk3sO6iK5QYnCqALILuwR7p7Mrw+IV0rqDLwm4GeH4jtN208RSjmugnowhyTBu XKppcnuNI/qeGDVoxnJ3paCCArcEHNUuOgzFeQiztl0Jvrufe7dH+nvO0BOJUfCsLEfz cABp/1f1B2OTsfE075Bww9U2DouuWW2tt956GR+SDmkWb0Rg1A7/UflwtsOavVKhoHtE +iRg== MIME-Version: 1.0 X-Received: by 10.55.33.213 with SMTP id f82mr5280510qki.107.1436263819965; Tue, 07 Jul 2015 03:10:19 -0700 (PDT) Received: by 10.140.36.233 with HTTP; Tue, 7 Jul 2015 03:10:19 -0700 (PDT) Date: Tue, 7 Jul 2015 12:10:19 +0200 Message-ID: Subject: adaptive rwlock deadlock From: Philippe Jalaber To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 10:10:21 -0000 Hi, I am facing a strange problem using the network stack and adaptive rwlocks running Freebsd 9.3. Basically I can reproduce the problem with 3 threads: 1) thread 1 has taken the rwlock of structure inpcb in exclusive mode in tcp_input.c. This thread also runs my own code and repeatedly takes a rwlock (called g_rwlock) in shared mode and releases it, until a shared object is marked not "busy" any more: rwlock(inp_lock); .... do { // thread is active waiting in the loop rlock(g_rwlock); o = find(); if ( o == NULL ) break; busy = o.busy; if (o != NULL && busy) runlock(g_rwlock); } while ( busy ); if ( o != NULL ) { // do something with o .... } runlock(g_rwlock); .... 2) thread 2 wants to set the shared object as "ready". So it tries to take g_rwlock in exclusive mode and is blocked in _rw_wlock_hard@kern_rwlock.c:815 "turnstile_wait(ts, rw_owner(rw), TS_EXCLUSIVE_QUEUE)" because thread 1 has already taken it in shared mode: wlock(g_rwlock); o = find(); if ( o != NULL ) o.busy = 1; wunlock(g_rwlock); // o is busy so work on it without any lock .... wlock(g_rwlock); // thread is blocked here o.busy = 0; maybe_delete(o); wunlock(g_rwlock); 3) thread 3 spins on the same inpcb rwlock than thread 1 in _rw_wlock_hard@kern_rwlock.c:721 "while ((struct thread*)RW_OWNER(rw->rw_lock) == owner && TD_IS_RUNNING(owner)) " My target machine has two cpus. Thread 1 is pinned to cpu 0. Thread 2 and Thread 3 are pinned to cpu 1. Thread 1 and Thread 2 have a priority of 28. Thread 3 has a priority of 127 Now what seems to happen is that when thread 1 calls runlock(g_rwlock), it calls turnstile_broadcast@kern_rwlock.c:650, but thread 2 never regains control because thread 3 is spinning on the inpcb rwlock. Also the condition TD_IS_RUNNING(owner) is always true because thread 1 is active waiting in a loop. So the 3 threads deadlock. Note that if I compile the kernel without adaptive rwlocks it works without any problem. A workaround is to add a call to "sched_relinquish(curthread)" in thread 1 in the loop just after the call to runlock. I am also wondering about the code in _rw_runlock after "turnstile_broadcast(ts, queue)". Isn't the flag RW_LOCK_WRITE_WAITERS definitely lost if the other thread which is blocked in turnstile_wait never regains control ? Thank you for your time, Regards, Philippe From owner-freebsd-hackers@freebsd.org Thu Jul 9 03:22:43 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBF54997B0F; Thu, 9 Jul 2015 03:22:43 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53F2711BD; Thu, 9 Jul 2015 03:22:42 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-f799a6d000007db3-ad-559de8fbe976 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 28.CD.32179.BF8ED955; Wed, 8 Jul 2015 23:22:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t693MYG7007378; Wed, 8 Jul 2015 23:22:34 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t693MWWO001607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jul 2015 23:22:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t693MWJx010848; Wed, 8 Jul 2015 23:22:32 -0400 (EDT) Date: Wed, 8 Jul 2015 23:22:31 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Call for FreeBSD 2015Q2 (April-June) Status Reports Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6novv7xdxQg0MvJC12XTvNbjHnzQcm i+2b/zE6MHvM+DSfJYAxissmJTUnsyy1SN8ugSvj9v1m9oIO7orNf0+yNTBO5+xi5OSQEDCR uPazkRHCFpO4cG89WxcjF4eQwGImiWVvfzFBOBsYJS6/+M8K4Rxkkvhx+jRYi5BAvcSRA3tY QGwWAS2JhtcL2UBsNgE1icd7m1khxipKbD41ibmLkYNDREBeYsF5e5AwM5D5/8plJhBbWMBG 4sytdWCtvAKOEjs3fwOLiwroSKzeP4UFIi4ocXLmExaIXi2J5dO3sUxgFJiFJDULSWoBI9Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXQu93MwSvdSU0k2M4IB0Ud3BOOGQ0iFGAQ5GJR5eje1z Q4VYE8uKK3MPMUpyMCmJ8po9AgrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4dVYCZTjTUmsrEot yodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgdXkO1ChYlJqeWpGWmVOCkGbi4AQZ zgM03Amkhre4IDG3ODMdIn+KUVFKnLcVJCEAksgozYPrhSWMV4ziQK8I814GqeIBJhu47ldA g5mABi/XnQUyuCQRISXVwKgS4allcf2gSKPyegu1p/cyluw7N+Pn5Vn77yhMuSQ0/bxiDeuy OfxpzPbi/17PnMa140lr11cbVw5N20NHj6SZPeBviTI0yBGf4/3srmyelNKBhhnb5qaov726 MbxQPXOB8Z2th8t/x7j8NHc6kDF71gfPfaJPgnvbjMMbmM65LYjraflitViJpTgj0VCLuag4 EQADJY0o8wIAAA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 03:22:44 -0000 Dear FreeBSD Community, Only one week remains before the deadline to submit entries for the next FreeBSD Quarterly Status update -- the deadline is July 14, 2015, for work done in April through June. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2015Q2 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-10-2014-12.html [5] http://www.freebsd.org/news/status/report-2015-01-2015-03.html From owner-freebsd-hackers@freebsd.org Thu Jul 9 09:55:53 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45DFE996A2C for ; Thu, 9 Jul 2015 09:55:53 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC0FD11F9 for ; Thu, 9 Jul 2015 09:55:52 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from [194.95.197.2] by 3capp-gmx-bs44.server.lan (via HTTP); Thu, 9 Jul 2015 11:55:43 +0200 Message-ID: From: =?UTF-8?Q?=22Carsten_B=C3=A4cker=22?= To: freebsd-hackers@freebsd.org Subject: Problem with jail and special rc.conf (disabling everything) Date: Thu, 9 Jul 2015 11:55:43 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:rmcReNOZgvu3I/tS9pzJMwMrBeajfEOHKJjR0F9Wuzm JJ3zXB3YF3OpjgkLueuFGweBLriExPy8kMhZditqNlWfhk9k6m QDdG4BaKLEDHnnQMpdsZhB1gC0XznBXdvknHmEtk/XgGHI4dup Qi1cH3HzjgQ2metatGkGl/7XFdM6eOFxMIsbc+zZhK11ZjcfF1 ToXiJ608lkUMJ4vS1lVTfFeGCncDiMi6hL5MdGBvqcgv1nEy3R xP/lCP6DMLqqqggF99HnyfYA5sNafPuCZi4ug9FPCCE6B9DJkq G9eLas= X-UI-Out-Filterresults: notjunk:1;V01:K0:5S4ISNWCYfc=:HCc/TZ9Ql4VeWsCzuQAptQ nlArytU9yy1NoV2ERPsLViBqhIAiplcLwqCV+r41bzgPs7Y6udniBHST1RyJ3AwCHI68iqnqh SO/dsRAe5lA2JvotRrWzgjEGNbOYtDdVVdx0aAJJjg0jjG6AzUpdKWDLpTcJJB9BlrgJQ5xkm h/zJBUFfy8D7oob584gJGLxsK4YIBENFHuCMIXJ4cVZc2P7mGhWCH3oY4nxXzaQOEKxrgaWpb PoVVfD1cRymSLRvboSw8D60LVpdNvDY2QT1BJuUI/Q8tEzVS1+wS0AhzkG4GV+KGJ3uFm1Q3+ 5RjYMh1GHWb/gzt193b2Hx5sN8tkVry26tsAG/jPUR8jXOncnyArjGsTIgAtvqVajjBuTM+KR kLAZv+KmPwiVMrU6qTsBD+ztEWwWAOJyZe9c5nI5PiKsHHrWKB5hrwoPaYuJRhDW7+fCf6d5U rmJtsd+6Ig== MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 09:55:53 -0000 From owner-freebsd-hackers@freebsd.org Thu Jul 9 14:03:16 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA47F9967C1 for ; Thu, 9 Jul 2015 14:03:16 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A80911C2 for ; Thu, 9 Jul 2015 14:03:16 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from [192.168.178.27] ([93.135.156.62]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MexlN-1ZONWD2yAD-00OYwH for ; Thu, 09 Jul 2015 16:03:12 +0200 Subject: Re: Problem with jail and special rc.conf (disabling everything) To: freebsd-hackers@freebsd.org References: From: =?UTF-8?Q?Carsten_B=c3=a4cker?= Message-ID: <559E7F1F.4050101@gmx.de> Date: Thu, 9 Jul 2015 16:03:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:nj151f4rF4dgxvc+EEpC2mbQKNa0GFpRa24cJhqUIP6Yco845p1 dRVvsOLv1xcQqbxr1ifGsqTE/jdUYsFBa5ZzgamtFhEt6zIFnTQfIc/sXfVkguI8zhtgc64 YWHymrAkMNBMe0jD43BYuqAN71YMfbCfIYoRHOCf4JoBeTDRHy7+U10kd2eP8U/xqSm78m4 rk6zH/MGPPB9XJ2joQcDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZOybVAVLrpE=:MBDeB9+frdoCS78kHQxuul qo7jZISHbS5zApdsNOKrd/sjG6ommV9bN8FAWw69svvHrOE9umn0ciA/Sv8z1DnLTErkCC+We RRyo3dk1rbzv9f9yh55lhhvZkyibRCH5ESd1tYjCn13by5V6MaSiuk6uvq2w/u18qKr7kmCbm 4H42VFgDBNNM9JEua7nz9/+Q95hJUYPx7xVcRfCkMKhc6qO04LouseBRUr/C/E/N6hUejJcpk oo4dfwACrArCkgNCJZEPy6CoYt3Jv1SBNr29Tyufi4R5wT0uhxAgpGYYQP5ENX8p2D/KvrtXH FkhYmGs1/cPFw30+5v81WxgJyOAAYae2W59Bd2tN849EyvgZMKBeoiiss/WNzl0frWmQ0oJSW NcVRau+VyqtdlWAjXNFLwqvnoQ2Z/DuFzh4K59CekWI9iiSc4CGm2SinuHyKWcZYahU/2LBCI bBhaSfog0BXhc07MHwMrTdeJKXFu8vXIfNNyxpXroY2j20rSPAsA5Js8vmINh+E0C0t5Yjiff jMddniCm1rh5DDYJoAAwzSfqe+V4/qYYABk1FZ4IRWGW+S++N29lZPS/RY83zaxulh28q3ADX T4ukCaKjx0qLTNVlEjdub6QvZTFNbaiAO6I3q2zx+lGQ1tMwvAoBC2Zkb76HD2IQeoP/SuQfw bedKU4OlhxwxtsMmsidt43ucFIbo5ggXaLwtg9bse01G/J9cH5yKPXuTGPSVyv3KsjY0= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 14:03:17 -0000 Hi hackers, sorry for the empty mail, I guess jails were not my only problem this morning, because outbox contained the complete mail. Anyway, i got the jail-problem fixed, so don't care about it. Best Regards Carsten Am 09.07.2015 um 11:55 schrieb "Carsten Bäcker": > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Jul 9 20:34:20 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7C11997DB2 for ; Thu, 9 Jul 2015 20:34:20 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 395A31553 for ; Thu, 9 Jul 2015 20:34:20 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LcSAg-1Yl9FN2nf4-00jtoD for ; Thu, 09 Jul 2015 22:34:12 +0200 Message-ID: <559EDAB8.9080804@gmx.com> Date: Thu, 09 Jul 2015 13:34:00 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD-Hackers Mailing List Subject: format/newfs larger external consumer drives Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yV3MWAPZZMDSyaOp8ugc3Tb6g++5F3bV0j1lVfibNL1alv4wfHh rLusKQZckKMEhhMryXPrS1s0D2BIbboAQHc0XTAJL5xnQCE0pj9gW5nr8Ri2TIiK58tRzqe As4/K1w4rF2cQ6xjqvjlwdoiwq7ojcK8Z1asuUjL1duuNPpMNbTfNNwlSWtCXpE0CN3+oPE 8f6HBnOeftb9q8/WgrAQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:hdD73ib0pL8=:ypmk+PB5K9oUYdhVdgR9CK gdvmrFS/mQlbX92JKzTJWm2Zo5byztocjLbcYsy3gsKu5kpJDLfI5NOUPy2EOhVaBPkpnFKAI MYShpOVXvLU9T4ZH5zR8ZaNjLD8suy3bafsZ+Ryz6n9ri+yTYwi92na7EMDXCtmbE3oyoK0S2 PlGlIPMYh0F22jRfwcQaKPDwIRDfclQ++PtrBP0QE9Z7dBxeWJvBVU85276Yex2dUgRTCuKTM 2NSdW3x5VkEyqyTuNwOVt4BalPOVqqLvcsvwvoZnlPTuRqhyffmvpZfmcrm0AkqakkZTWy4Zk EiqCE92CbaoyVaQ9Lx2kIQ5Q5jPvBRznQEAY0iAC+NGhDycFvNjiQsG8HMquJjajygOOqS+TY o5cSwh0w6hnoMmfr2wMNBnVWXJ8ie9MuqnxNvbjBb76gv++nm0gIIMa9KaVK46aO2AvdBSY6+ sCj12R26GsBxWTwT6KoGNbRoXh6VzfbqiLRBtA4q8AxxA8b7SKtyjvuGBz6qAAyt2kHJ+U1yX kmlsF5TrpqbgRQX82MmLvsH8Doo+dth8T8fWm8b2akUJhTVP3xS90mfP7J557c+yRpFJEtxoj AzzSiXNNTB58YVKFbHMU6GbImS3C2CJ8cJQa+x7Vmzsq/mtw4hqe7e8S5/tLaJnB8pSr2u9UB I7I8Ruc7N31CMidG9WsQU+O4wJ6o6LB+N4A4Hh16TxUZxHchHDbtKl6fbNX1jYpTJjvM= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:34:20 -0000 Hi, When building a filesystem (FFS) on these 1/2/3/4TB external USB drives, any suggestions? E.g., changing block sizes? Cut into multiple slices to make fsck's job easier (as well as *recovery*)? Any other pointers? [Note that I'm not looking for "performance" -- otherwise I wouldn't be going the external route -- but, rather, "bulk, semi-offline storage"] Thx, --don From owner-freebsd-hackers@freebsd.org Thu Jul 9 20:42:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C352997F5E for ; Thu, 9 Jul 2015 20:42:04 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B18921B6F for ; Thu, 9 Jul 2015 20:42:03 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LoVOE-1YWmoV0wRe-00gcYv for ; Thu, 09 Jul 2015 22:36:49 +0200 Message-ID: <559EDB56.70808@gmx.com> Date: Thu, 09 Jul 2015 13:36:38 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD-Hackers Mailing List Subject: Xorg for client-only support Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nvPKFdSd1IQUZ96Ocee7xYtuV0vzRxgvUaenC/1ABv4Jj55nAak KZeq1earQysgtIZflKOzXVTIpvEM1+XjBFACwIdmfM1lDjGIMnxcyavml9CYoYr+XBQmGDe k6fFk68byMWifmsD9gkdQTTtn1WcnUYTjPhL+myBaeMUY3/0QBWh7dtxNQ6m5XNlSokCk6g 0Iu5UJXu6CwFB+KXQCT6Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:DgdFoyg2zUw=:blMA0NeyC9VzBwbpb0ukFh SML2SRQOLr+4p/0MTZbwK/X+NvgekYeF+vYl5rrvHQdFJ2X7wtkfVCpIMqv9dvtQ46gyCpHEc IdieibcIxVXIxQEH3YtZ6QYRlQWVNLAp1ABhkm1J1j4twtA738R4vZ1SW6ZA0VB93kNX4BPvE hfVqxH6PI4MAWSNpAPPswHHB+td1xcbF1VfySeMiIeeuz+fgPS/vQPSWLisEymPIelmeHaAaE YCfbB93cemkgBuPqPxBm14+HJl25wXwnC4t/KfZJIv9AfDd88L4c0a5U+vWbPpmPnVPq/nAyo /1/8Z27eVhQd0DwwQHB9CvW7Jc062MwnBiwko6g1Kepgm7/oXx7BT5Iium875jxek690sub7I LzwYOGoxH3G8LqcbCAfyKPwr8KkJbHRGiFEZSMfzmabQWocKWPkWDVB5NdMNigJdJeV8ItObi 5LrpXnYHWMLWozTBOSsthwmMwokcgNg/4GSOCopdD5C0Y/5OAviFweP3ms0bWKy2Epj1r5/Tx r7FcNVD0nK/SmmdlgMszWBC6c6TS8FejdBleBuwHNt6Qoq75VgS5UHIQXX6CqvNgMx+X9EUTF JMdppIfJDp1GHpA0DbFt7WbQxDvK7Dq9nL3/oRpU59K03pSG6hL1JszP2a/UAUdfNBtAiYaZs 24rdECld0n1hbesvRc7NBVjZpBsvhznT4dzXb73ynMMrfmvsaVI93mUw0RLqJlACmzvk= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:42:04 -0000 Hi, For *headless* devices (i.e., no point in having a real *server*!), are there significant portions of xorg that I can omit? Or, is it easier to build and install it all and remove the unnecessary cruft, later? [I'll be building from source, not installing a prebuilt package] Thx, --don From owner-freebsd-hackers@freebsd.org Fri Jul 10 00:22:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CECE339F7 for ; Fri, 10 Jul 2015 00:22:12 +0000 (UTC) (envelope-from cary@sdf.org) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by mx1.freebsd.org (Postfix) with ESMTP id 9276DA5D for ; Fri, 10 Jul 2015 00:22:11 +0000 (UTC) (envelope-from cary@sdf.org) Received: from [67.49.10.59] ([67.49.10.59:13319] helo=bsdstb.Belkin.invalid) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8C/19-13217-D201F955; Fri, 10 Jul 2015 00:22:05 +0000 From: Cary To: Don whY Cc: freebsd-hackers@freebsd.org Subject: Re: format/newfs larger external consumer drives In-Reply-To: <559EDAB8.9080804@gmx.com> (message from Don whY on Thu, 09 Jul 2015 13:34:00 -0700) Date: Thu, 09 Jul 2015 17:22:03 -0700 Message-ID: <86fv4wdfpw.fsf@bsdstb.Belkin> MIME-Version: 1.0 Content-Type: text/plain X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 00:22:12 -0000 Don whY writes: > Hi, > > When building a filesystem (FFS) on these 1/2/3/4TB external USB > drives, any suggestions? E.g., changing block sizes? Cut into > multiple slices to make fsck's job easier (as well as *recovery*)? > > Any other pointers? > > [Note that I'm not looking for "performance" -- otherwise I wouldn't > be going the external route -- but, rather, "bulk, semi-offline > storage"] > > Thx, > --don Before worrying about fsck(8) I recommend you think about using geom(8) to put a journal on the device if your plan is to create a FFS filesystem. The journal consumes some drive space but for any filesystem over 20-30 GB it won't limit your storage capacity very much. I do not have any external drives formatted with FFS, and I would be interested to know myself if it is at all possible to use gjournal(8) with an external usb drive. Someone else on the list must know the answer to that question. You should read the man page for gjournal(8) and note the part about disabling soft-updates and using the async mount(8) option. There is a short intro to the topic in the handbook. http://www.freebsd.org/doc/en/books/handbook/geom-gjournal.html Cary From owner-freebsd-hackers@freebsd.org Fri Jul 10 03:48:57 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDAC5995CB8 for ; Fri, 10 Jul 2015 03:48:57 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D35A1F19 for ; Fri, 10 Jul 2015 03:48:57 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by wifm2 with SMTP id m2so35087628wif.1 for ; Thu, 09 Jul 2015 20:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u3EO2TV478+fVfYee7EFaFH022q3LOWJehknyWAI4iM=; b=jNwz9IzTOvggnlZ4LwLbUivlG/BrwMANCcQFPeGT1xaa/f0r0lvASP3quseaANIFyf v0nsO2H5jUM9GNiuUE0yrJ6Ya00o+fNT/4L3ZymJRCyM8keJ4BaGDEWHXKxLCw4KuPn0 /80yJTa4kVel3RZ4CB4ZRHkodPUyp+85ErHYRsBryWHxPXp+8AgK55RjhE2yaPN801J0 cj0CPHKi9IFIwfJeHnjyykciZLQ9baxRJ9a6uG8XM99PtFqj9SOqPqJaZ91pKef107vy bpgOtclub5hq4j1sAnmUmdUuimgOgocxQCW8JAnc1ETfsgY0eU4jDmi4TSqqqSGpT4FA ME3Q== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr2109847wib.60.1436500135894; Thu, 09 Jul 2015 20:48:55 -0700 (PDT) Received: by 10.194.64.102 with HTTP; Thu, 9 Jul 2015 20:48:55 -0700 (PDT) In-Reply-To: <5590025E.9030907@metricspace.net> References: <5560F4FE.4030502@metricspace.net> <5560F743.9000507@metricspace.net> <7CD9D028-8BCE-4361-966B-140642BAE341@metricspace.net> <98598C0A-D09A-4BC7-A15C-5422BBA2EE4C@gmail.com> <55761E58.6040704@metricspace.net> <5590025E.9030907@metricspace.net> Date: Fri, 10 Jul 2015 06:48:55 +0300 Message-ID: Subject: Re: EFI ZFS loader successful load and boot From: Andrey Fesenko To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 03:48:57 -0000 On Sun, Jun 28, 2015 at 5:19 PM, Eric McCorkle wrote: > On 06/28/2015 01:39 AM, Andrey Fesenko wrote: > >> Unable to load the kernel, i'm make simple gpart structure >> >> GPT >> efi part <- write /boot/loader.efi as efi/boot/bootx64.efi >> ZFS root pool > > Just saw this part. You want to write /boot/boot1.efi to > efi/boot/bootx64.efi, not loader. > I tried to try a new boot loader again, unfortunately, once again failed to load, but it turned out a few facts: loader start with clear environment (loader device efi, not zfs env), https://bsdnir.info/files/efi/ screenshot lszfs - efi-zfs-notenv.jpg, zfs_get.txt and zpool_get.txt contain zfs/zpool get all list's If possible, put the master image of the for recording to the flash that we could rely on him. From owner-freebsd-hackers@freebsd.org Fri Jul 10 04:12:56 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AA243392 for ; Fri, 10 Jul 2015 04:12:56 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id D9C17D65 for ; Fri, 10 Jul 2015 04:12:55 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038] (unknown [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 5A3101136; Fri, 10 Jul 2015 04:12:47 +0000 (UTC) Message-ID: <559F463D.8020402@metricspace.net> Date: Fri, 10 Jul 2015 00:12:45 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrey Fesenko CC: "freebsd-hackers@freebsd.org" Subject: Re: EFI ZFS loader successful load and boot References: <5560F4FE.4030502@metricspace.net> <5560F743.9000507@metricspace.net> <7CD9D028-8BCE-4361-966B-140642BAE341@metricspace.net> <98598C0A-D09A-4BC7-A15C-5422BBA2EE4C@gmail.com> <55761E58.6040704@metricspace.net> <5590025E.9030907@metricspace.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2eJ2LF3PeoHqJR9s36FdaA7tGri21mA5w" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 04:12:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2eJ2LF3PeoHqJR9s36FdaA7tGri21mA5w Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/09/2015 11:48 PM, Andrey Fesenko wrote: > On Sun, Jun 28, 2015 at 5:19 PM, Eric McCorkle w= rote: >> On 06/28/2015 01:39 AM, Andrey Fesenko wrote: >> >>> Unable to load the kernel, i'm make simple gpart structure >>> >>> GPT >>> efi part <- write /boot/loader.efi as efi/boot/bootx64.efi >>> ZFS root pool >> >> Just saw this part. You want to write /boot/boot1.efi to >> efi/boot/bootx64.efi, not loader. >> >=20 > I tried to try a new boot loader again, unfortunately, once again > failed to load, but it turned out a few facts: > loader start with clear environment (loader device efi, not zfs env), > https://bsdnir.info/files/efi/ screenshot lszfs - efi-zfs-notenv.jpg, > zfs_get.txt and zpool_get.txt contain zfs/zpool get all list's >=20 > If possible, put the master image of the for recording to the flash > that we could rely on him. >=20 Definitely something weird going on. The most obvious next step as far as I can tell would be to actually look at the partition type GUID's. Here's a theory as to what might be going on: 1) Trying to load a filesystem that isn't actually that FS type somehow messes up the state of the fs loader code in ways that break future attem= pts 2) Doing legacy first causes the BIOS to order the partitions differently than it would if you do UEFI only 3) Because the current boot1 blindly tries to probe everything, it gums up the FS code, but switch the order around and it works (because it didn't probe a wrong partition first). I'll try and get the partition type GUID check done this weekend. As for loader, it reminds me of issues I had to fix to get loader working in the first place (which suggests I missed an edge case). Basically, loader has a device info struct (I forget the exact name) for describing devices. But ZFS devices need additional info, so I did a quick fix of re-allocating the struct with the additional space if it's a ZFS device. A better solution would be to add padding space to the device info struct, similar to what's done with struct sockaddr. Then specific subclasses could store their data in the padding (like struct sockaddr_un and struct sockaddr_in), but you could still refer to it by the more general type. It seemed like a bit too progressive of a change, but in light of this, it might be the way to go. --2eJ2LF3PeoHqJR9s36FdaA7tGri21mA5w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVn0ZBAAoJECuREQPg1IcESQsP/1wl8wUP8WbirB7/fDDE0mfU 2xSJFmSA3NN3vyx87MT/JlNrchQ1RD759FfFwNTxRg5NntZ5pWPOAgrW5C6xyo94 g9AxQ8fmDMAhXQbrP154psPvKSHjjK6ax81pTGQYHHNc7NryqF0jLfmyfWYAKGxW G8tPUuDQNCNFzIshp5J5OeHNJ9ZpkiJUWgN0uzoJ0ee7Nj0RlcEtXJF5lOxSh0dJ D4/uHEzQYClMg9jzYXWPlhZRNjcIl89b9OsT0mgm1KBg3+w4UdMbDZqWvtos9tSQ FkLDpe13ZQGROrCFsgzyowqIHmDcC0T/32sAc01M7AYnpIePodboTBvCHnYWbpVA LsoTmLViDkBpWiYLBYd8bMd+cRYLQ8ujvllOH6UP19eNJ2x3waSZRcbTJzOvuL8X UUA8jycjWCni9aWI5zyASTPr8YI2V1cWMXgTg9/sPQFLBMpvuukpSsP5m2fqURIt AxlLvn5d7F7ctl4Io/8txZUIQNo3B8O2l37yDGXLjAM12fVwmiIFUvHLj143Q3TR 534Uh1rAmHEvLwV5xnSx8DRh/wyfUmO5jU9bRbHqy5F/yr2UcKDHDjPLmEwjSOWn 6SEEBsA8rRTs1YxL6qSQ0iKGkKlKX0oVqqeAfWrJ92OWZFa3hP2zbc0A8VxDDfjS 1PFyLFuAhsn1lGzmuyfi =Mym/ -----END PGP SIGNATURE----- --2eJ2LF3PeoHqJR9s36FdaA7tGri21mA5w-- From owner-freebsd-hackers@freebsd.org Fri Jul 10 14:18:32 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EF4439A4 for ; Fri, 10 Jul 2015 14:18:32 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E346E3E9 for ; Fri, 10 Jul 2015 14:18:31 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t6AEIOPR055216; Fri, 10 Jul 2015 16:18:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 974B5CDF; Fri, 10 Jul 2015 16:18:23 +0200 (CEST) Message-ID: <559FD426.3000108@omnilan.de> Date: Fri, 10 Jul 2015 16:18:14 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Ambrisko CC: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> In-Reply-To: <20141101154004.GA40398@ambrisko.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig059C4B624A70748D42259D0F" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 10 Jul 2015 16:18:24 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Fri, 10 Jul 2015 14:41:05 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:18:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig059C4B624A70748D42259D0F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > | Hello, > |=20 > | first sorry for the missing thread references in the header, I'm not > | subscribed to hackers@. > |=20 > | bdrewery@ pointed me to this discussion in response to my question to= > | stable@ > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.htm= l) > |=20 > | Last promising post I found: > |=20 > | > |/ > I have a new patch at: > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch > | > /|/ > that I tested against head. This should be pretty close to c= ommiting > | > /|/ > unless people find some issues with it. > | > /|/=20 > | > /|/ In sys/kern/vfs_mount.c: > | > /|/ + mp->mnt_path =3D malloc(strlen(fspath), M_MOUNT, M_WAITOK); > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > | > /|/=20 > | > /|/ This always strips the last byte off the fspath. > | > /|/=20 > | > /|/ I like that this only touches the kernel, so it does not break = anything > | > /|/ regarding mount/umount of filesystems with short paths, includi= ng > | > /|/ (NFS) filesystems that do not respond. > | > /|/=20 > | > /|/ The patch does not enlarge f_mntfromname which may be a problem= for > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAM= ETOOLONG] > | > /|/ errors could still occur in more extreme situations. > | > / > | > Good point on nullfs. I'll look at fixing that. To do that I'm > | > changing mnt_path to mnt_topath so then I can have a mnt_frompath. > | > I'll add nullfs to my test cases. I'll need to run through the use= s > | > of f_mntfromname. It was pretty easy with f_mntonname since it was= > | > only allocated in one place just used a bunch of other place. I as= sume > | > that mount root would be short. > |=20 > | Thanks a lot so far for working hard on that problem! > | Is there anything newer than "mount_bigger_2.patch", which considers > | potential nullfs problems? > | I'm heavily using nullfs (without poudriere), but I'd give it a try o= n > | my rather lightly loaded local 10.1 storage box ??? almost all snapsh= ots > | are useless, can't access them in case of the case; which happens > | frequently :-( > | Would I have to expect any nullfs regressions with the april > | (mount_bigger_2) patch?? Bez=FCglich Doug Ambrisko's Nachricht vom 01.11.2014 16:40 (localtime): > I should be able to resume working on this since things are starting to= > slow down. It shouldn't be much more work to get it finished off to > put up for review. Hello Doug, I've been using your mount_bigger_2.path for some months without problems, but haven't done any kind of stress test. It just saves my soul in case I have to recover files from (zfs-)snapshots from time to time :-) Since releng/10.2 is to be created soon, I'm testing RELENG_10 on some of my production machines, Therefore I cosmetically altered your patchset to make it work with -stable: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/local-patches/RELENG_10/mou= nt_bigger_2_1.patch Have you made any progress in this area, e.g. is there anything different I can test, which might help in any way? Thanks, -Harry --------------enig059C4B624A70748D42259D0F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlWf1C4ACgkQLDqVQ9VXb8iIwACgny7GbWjZMQi2v/5dd2lg66Bt ZWcAoIgZaQhGJhacniSWYYBkxI6+ok0u =ZFbh -----END PGP SIGNATURE----- --------------enig059C4B624A70748D42259D0F-- From owner-freebsd-hackers@freebsd.org Fri Jul 10 15:48:03 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5A10997389 for ; Fri, 10 Jul 2015 15:48:03 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id BCA401CFC for ; Fri, 10 Jul 2015 15:48:03 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 10 Jul 2015 08:46:55 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.9/8.14.4) with ESMTP id t6AFktT6072976; Fri, 10 Jul 2015 08:46:55 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.9/8.14.4/Submit) id t6AFksWL072975; Fri, 10 Jul 2015 08:46:54 -0700 (PDT) (envelope-from ambrisko) Date: Fri, 10 Jul 2015 08:46:54 -0700 From: Doug Ambrisko To: Harald Schmalzbauer Cc: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20150710154654.GA71708@ambrisko.com> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559FD426.3000108@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:48:04 -0000 On Fri, Jul 10, 2015 at 04:18:14PM +0200, Harald Schmalzbauer wrote: | | > | Hello, | > | | > | first sorry for the missing thread references in the header, I'm not | > | subscribed to hackers@. | > | | > | bdrewery@ pointed me to this discussion in response to my question to | > | stable@ | > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) | > | | > | Last promising post I found: | > | | > | > |/ > I have a new patch at: | > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch | > | > /|/ > that I tested against head. This should be pretty close to commiting | > | > /|/ > unless people find some issues with it. | > | > /|/ | > | > /|/ In sys/kern/vfs_mount.c: | > | > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); | > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); | > | > /|/ | > | > /|/ This always strips the last byte off the fspath. | > | > /|/ | > | > /|/ I like that this only touches the kernel, so it does not break anything | > | > /|/ regarding mount/umount of filesystems with short paths, including | > | > /|/ (NFS) filesystems that do not respond. | > | > /|/ | > | > /|/ The patch does not enlarge f_mntfromname which may be a problem for | > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] | > | > /|/ errors could still occur in more extreme situations. | > | > / | > | > Good point on nullfs. I'll look at fixing that. To do that I'm | > | > changing mnt_path to mnt_topath so then I can have a mnt_frompath. | > | > I'll add nullfs to my test cases. I'll need to run through the uses | > | > of f_mntfromname. It was pretty easy with f_mntonname since it was | > | > only allocated in one place just used a bunch of other place. I assume | > | > that mount root would be short. | > | | > | Thanks a lot so far for working hard on that problem! | > | Is there anything newer than "mount_bigger_2.patch", which considers | > | potential nullfs problems? | > | I'm heavily using nullfs (without poudriere), but I'd give it a try on | > | my rather lightly loaded local 10.1 storage box ??? almost all snapshots | > | are useless, can't access them in case of the case; which happens | > | frequently :-( | > | Would I have to expect any nullfs regressions with the april | > | (mount_bigger_2) patch?? | | Bez?glich Doug Ambrisko's Nachricht vom 01.11.2014 16:40 (localtime): | > I should be able to resume working on this since things are starting to | > slow down. It shouldn't be much more work to get it finished off to | > put up for review. | | Hello Doug, | | I've been using your mount_bigger_2.path for some months without | problems, but haven't done any kind of stress test. | It just saves my soul in case I have to recover files from | (zfs-)snapshots from time to time :-) | | Since releng/10.2 is to be created soon, I'm testing RELENG_10 on some | of my production machines, Therefore I cosmetically altered your | patchset to make it work with -stable: | ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/local-patches/RELENG_10/mount_bigger_2_1.patch | | Have you made any progress in this area, e.g. is there anything | different I can test, which might help in any way? It's been working fine for me. Glad to hear it is working good with ZFS. Kirk asked me not to continue with this since it would make the 64 bit inode work harder and that they were going to bump up the max of the mount point. He also mentioned that it couldn't be merged back since it changes the kernel API. So I'm not sure where that leaves us for now except that this works for us. I use it a lot at work since we mount things in chroot's of which the path is pretty long especially when we mount stuff in a chroot of chroot for our build process. It's better then my first attempt since the user space ABI didn't change. So it mostly just works except for listing the mount points get truncated. Thanks, Doug A. Thanks, Doug A. From owner-freebsd-hackers@freebsd.org Fri Jul 10 16:41:09 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DF30997BDE for ; Fri, 10 Jul 2015 16:41:09 +0000 (UTC) (envelope-from patrickhess@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA7A1AC2 for ; Fri, 10 Jul 2015 16:41:08 +0000 (UTC) (envelope-from patrickhess@gmx.net) Received: from desk8.phess.net ([95.88.11.237]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MgcTf-1ZOmrG06wp-00Nxxn for ; Fri, 10 Jul 2015 18:41:05 +0200 From: Patrick Hess To: freebsd-hackers@freebsd.org Subject: Re: Xorg for client-only support Date: Fri, 10 Jul 2015 18:41:03 +0200 Message-ID: <2863155.VvqRCPmh7x@desk8.phess.net> User-Agent: KMail/4.14.3 (FreeBSD/10.1-RELEASE-p10; KDE/4.14.3; i386; ; ) In-Reply-To: <559EDB56.70808@gmx.com> References: <559EDB56.70808@gmx.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:YAkBv3AiVkquV0N4ixoFrhVAO5m5Pr5uz6h3MD12TXBoq4pOxEr yLZDa3TxkNaIlqHWmF4Pe+UGC2pvlxbClzeZk/QQ/3KeWf0vK6oc+wKbAHr3IcGLsJ80obg 8kSNyknv027uo2bw3zfZHw8t7+3vY1bpx5NhOvM3pK+uuvYWD7RXeHLrH2GB2/bjyG5ItSn SAf/ESO4U6NeZR1qwvmvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:VOmYDfgHvZ8=:wjOHf3wYwQ8AzfA4jYx2U8 i5LWnJrw0kqr1E6SnsF3AdyXqazLitRtrRhj1c+psnG49sBusSe1sdFbPaw/GkkhC1W/sylUT ugofBkJrjjHhO1EEShU9bBgGarFqdyJ4hbD1R8a3D1ikKaKM3VsbBWkWKO0xAqPQ59B+fPJrS nDLRc8nGXjOQOVA4UAiNV/nyejL/0BoTRLo5qdW0bhI6V4a38Sc8Dg6+xADWmEk4loY9CDlTW Zdbsd+X/SOc+/c7qYLcLHiGRMIBmFJleAF76OHE5pCXufc7T0xWckhimqPP07QkdEZZAE6MK7 r+DE75TX7Kf+DG6sbnHNeuJiQuWU9M1S/yihz66Lo0pMsRv2CykreKyNrt1yEgzLu8N3wMyB5 Tlm+VBHDLk4QY9PdHJR+4I8ko1ep6khXw8knUjdppcrjx30qpltuIeU4Byp6VqCs28iSsYTUA FUQR41GVSCFJF3XwxKG2p7p5upuTgdMeaWHadt/VVzMS+UU5d+QwEktuJPuAyWyPMkzUlqMj7 KrwKPV91okJdDcLdxuSpNJ0CSWRgiVFpJRsdWrBYtsjXPquSZEwv73VSB5dAvY2I31OOeVuU7 QGcjnSjsI5NF4jKzQJEQjfGllwHg9IXrnKQvsUPIm3Cra6CIZfYCN1PRaQzUqUjpbL88C7IkV Y59EfnpEH74xQh6ugotV9K9Mo+tTjRI++hlkhLERge5kI6nH+AndFsBxrBxmbaQ8C2hs= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:41:09 -0000 Don whY wrote: > For *headless* devices (i.e., no point in having a real *server*!), > are there significant portions of xorg that I can omit? Or, is it > easier to build and install it all and remove the unnecessary cruft, > later? Since you don't need the server portions, I don't really see a reason why you would want to worry about installing any X.org ports by hand. Just installing the applications you want to use should automatically pull in the X.org dependencies that are actually required by these applications. This will prevent any unnecessary parts, like server components and video drivers, from being installed on your system in the first place. Patrick From owner-freebsd-hackers@freebsd.org Fri Jul 10 16:44:11 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D79B997D19 for ; Fri, 10 Jul 2015 16:44:11 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EAD51D92 for ; Fri, 10 Jul 2015 16:44:10 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYOCL-1ZZCrw2LD7-00VCuI; Fri, 10 Jul 2015 18:43:53 +0200 Message-ID: <559FF63A.9020607@gmx.com> Date: Fri, 10 Jul 2015 09:43:38 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Cary CC: freebsd-hackers@freebsd.org Subject: Re: format/newfs larger external consumer drives References: <86fv4wdfpw.fsf@bsdstb.Belkin> In-Reply-To: <86fv4wdfpw.fsf@bsdstb.Belkin> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dAEoOeQ6GaYhVSw0sHtmtDDvlo3BUMF0s7fwrv77Hh2XNQf5E4g 5PsNkgbv3ALe4/1fqswjHWDCV+XeuQNjRegk4tKDR1jZlxFw1YwUrFspZj+ZAmG7PaUjcwO Qe5oxyri2aRCjvYsDZjlv6oE8TJKSF9MHplJnpdZjtF0AblEy6c/BTCZR+OhtQSRDEY6Jdv mCvcAfBhgvdN33zd4tJqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:C4O/oKe8/R0=:SX10HI4il1m5STZAfpJNNx 7eeB30/9LFWI+UBHc1zJ0IjJSguM1nbLv2byJohYT2kMgGFapmQv8fH9vUv/QtP/kZO3JY0kL xLxatx3kBf0ktCqxib/IfK92OsA/YykFJMBIADHunVPJlrfQfSNNC2kTJKQfy1wPWXW3x1pbW XhKZF/JXfrWIPwRonCQw8BXhwB5BsSZW+ZGCTp4WRg0OnQyoHm2g3lNMiz4/ox8I5VZ75p/jG Cvz3z7uVJIaYVmB87nzNfgB/tfAXpFc2lEgIqwpGJWvCTSF8xkrgJMT7xulj4rN/HgGamZJ7F V+wz9elHUC7N2s1OS09Jsj1mvmTZOWq2LlDgvbMSjt4z43mPhLw1bi9bzDv8rQ+8LMpBzUkwL 1R/8+bmVsSdP4Z1WrWts1haxD70g6bRqtH3X6NKE7rYh5HpMxgnDYZP9QJ7JCjK9B8faR206x QyD2d6cd5+V+d+snKOsAn2QpMwHuKo4aI/nNTp/KaFQAEZ8DuJv1duyDn0w/sExe034Mx3liK xTbIzv8kvpSHg12540Jx1OfldUWaek2OXZiCCM87Cq45P9UTKDnas2yRN8YUeEeaD9znj/gtM LNgVJFXj/zT+71L0H7csvrmJXBC5qL1GY4Hg82J0GGLKaFjsF8o8q1DtW0b4nPbXaieGbJEkp vZIYl9o2Bz8J8/WWR7knCRu5rTxWrMnTDWIBEpUeSLtJxfRs1uB55JAqJbvrX5n99utM= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:44:11 -0000 On 7/9/2015 5:22 PM, Cary wrote: > Don whY writes: > >> When building a filesystem (FFS) on these 1/2/3/4TB external USB >> drives, any suggestions? E.g., changing block sizes? Cut into >> multiple slices to make fsck's job easier (as well as *recovery*)? >> >> Any other pointers? >> >> [Note that I'm not looking for "performance" -- otherwise I wouldn't >> be going the external route -- but, rather, "bulk, semi-offline >> storage"] > > Before worrying about fsck(8) I recommend you think about using > geom(8) to put a journal on the device if your > plan is to create a FFS filesystem. The journal consumes some > drive space but for any filesystem over 20-30 GB > it won't limit your storage capacity very much. > > I do not have any external drives formatted with FFS, and I would be > interested to know myself if it is at all possible to use gjournal(8) > with an external usb drive. Someone else on the list must know > the answer to that question. > > You should read the man page for gjournal(8) and note the part about > disabling soft-updates and using the async mount(8) option. > > There is a short intro to the topic in the handbook. > http://www.freebsd.org/doc/en/books/handbook/geom-gjournal.html Thanks, I'll check into it. I'm interested in developing some guidelines for designing "appliances" where the hardware complement isn't typically as rich as a desktop environment (e.g., would *not* include a disk interface but *could* exploit an external disk, etc.). Of course, anything external means the user could insert/remove it at will -- which complicates how the system will deal with the resource. From owner-freebsd-hackers@freebsd.org Fri Jul 10 17:28:32 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92FA23549 for ; Fri, 10 Jul 2015 17:28:32 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1972C11C5 for ; Fri, 10 Jul 2015 17:28:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t6AGxVuR083281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jul 2015 18:59:31 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t6AGxQ51002089; Fri, 10 Jul 2015 18:59:26 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t6AGxL1X002086; Fri, 10 Jul 2015 18:59:21 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Fri, 10 Jul 2015 18:59:21 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Don whY cc: FreeBSD-Hackers Mailing List Subject: Re: format/newfs larger external consumer drives In-Reply-To: <559EDAB8.9080804@gmx.com> Message-ID: References: <559EDAB8.9080804@gmx.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Fri, 10 Jul 2015 18:59:31 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:28:32 -0000 > When building a filesystem (FFS) on these 1/2/3/4TB external USB > drives, any suggestions? E.g., changing block sizes? Cut into > multiple slices to make fsck's job easier (as well as *recovery*)? i would assume you will most likely store large files. newfs -m 0 -i 262144 -b 65536 -f 8192 -U /dev/yourdisk and it will be fast to fsck. From owner-freebsd-hackers@freebsd.org Fri Jul 10 17:56:42 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 663173A12 for ; Fri, 10 Jul 2015 17:56:42 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA2E672 for ; Fri, 10 Jul 2015 17:56:41 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MZTbR-1ZYrka2IXN-00LFfX; Fri, 10 Jul 2015 19:56:33 +0200 Message-ID: <55A00743.4080609@gmx.com> Date: Fri, 10 Jul 2015 10:56:19 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Wojciech Puchar CC: FreeBSD-Hackers Mailing List Subject: Re: format/newfs larger external consumer drives References: <559EDAB8.9080804@gmx.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hxasPBNYjO+6fzYpO80ADn5jaeD2aBSVL9f2+i7z3TyiqTSj77U db5hh+baYN98uFyawUaP/DABT7FYc5N+NDSkXWk0CsDodF+48hP3TVP17V3HaeY2Qb+maQM aeFzu5pXLpngMwPjRQVfWSYk+c6WoOOg9SafWT3aLNtoTj2u9963dq8FjJxl9PIG34tD6u2 OFBLW+xyJkSEX++hV16xw== X-UI-Out-Filterresults: notjunk:1;V01:K0:/BDWfIkcp2g=:dyfuwNqoVgKI1nuWbkSMDM 6c+4SQmENzMW5HqvYrLflv5LTX6688JqszwGeIhMfMHXChejKp9BsAU5in2KzuBxJh4A7mCad WPJLgDl4RFePWlsHdOygzRAY0Lc9GyRR55F0JajzcO9z5ZeUGGkLwHdtEYmmRQPEwgn9x4wBK Xk5QmvT8HTeT8j8lGU+5p4MP+XVJ7BYWYxAv+JCVmo8XNUO8aBm/YLRMbJi+GYJT1WzoQPNMC uso+XuxeiRel6wgXqC1U6uYl6klIFznynEg3Res8Zeg83Ztd+PQkX+px3Vlpfle+siJ6hyWC3 MkOaCqucxFQlLbsDxIsNjeDzeCPiKFfaeH0aLLlzCRDog2jZleSFU/TbLHqsPyG/OCc/UgjBT OdT45PONDztO2dCOwyqBgch9SAAk+sluNPBgjUuBw7q5M8IcN4oAY19syI6EyAm8k26NN+3RG QfpemVo7ucILhLOEUz1q+VY9pfzLyYpYIUoN9jLAP+hgf7PunhtGYjZr0daikKJK+7EKKda6x DeKvluZROlH6+ANO9XcV6L6wZxGufAl4BMXofRSh/0QxIZV2/N9AatMDoN/mdea0K6VpLpIMX +nao1hOjEcczl4jU+KcG3sxwvcFXs6vesY/w5oip/k6T9+k/JP90FqDdzXdS8U7R31w07blOE +k6uzE618bP9t/SOfYVhNAYd0YeZaXqu0ROCBiwNzwPl4K2J4RZcNfF25wRWN8p929Ys= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:56:42 -0000 On 7/10/2015 9:59 AM, Wojciech Puchar wrote: >> When building a filesystem (FFS) on these 1/2/3/4TB external USB >> drives, any suggestions? E.g., changing block sizes? Cut into >> multiple slices to make fsck's job easier (as well as *recovery*)? > > i would assume you will most likely store large files. For the demo application I'm writing up (to illustrate the issues that appliance developers might face), I would be storing large files (e.g., ISO's). But, some other developer/application might choose to use the medium for smaller files -- or even smaller media capacity. So, I'm trying to prepare a list of criteria to guide them in configuring the medium as well as their expectations from it. E.g., the "big" drives I mentioned tend to use 4K "sectors" while smaller/legacy drives are 512. I don't know if this can all be transparent to the user or if the developer needs to take special steps based on the actual medium being supported. The limited bandwidth of the comm channel to the (external) drive means little "mismatches" in configuration can have noticeable impact on the end user (e.g., he opts for finer-grained management and pays the price when a volume isn't properly dismounted, power fail, etc.) > newfs -m 0 -i 262144 -b 65536 -f 8192 -U /dev/yourdisk > > and it will be fast to fsck. > From owner-freebsd-hackers@freebsd.org Fri Jul 10 20:20:59 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DE8999706C for ; Fri, 10 Jul 2015 20:20:59 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89EA81F28 for ; Fri, 10 Jul 2015 20:20:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t6AKKq6g090814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jul 2015 22:20:52 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t6AKKm2r000780; Fri, 10 Jul 2015 22:20:48 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t6AKKggK000777; Fri, 10 Jul 2015 22:20:43 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Fri, 10 Jul 2015 22:20:42 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Don whY cc: FreeBSD-Hackers Mailing List Subject: Re: format/newfs larger external consumer drives In-Reply-To: <55A00743.4080609@gmx.com> Message-ID: References: <559EDAB8.9080804@gmx.com> <55A00743.4080609@gmx.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Fri, 10 Jul 2015 22:20:53 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:20:59 -0000 >> >> i would assume you will most likely store large files. > > For the demo application I'm writing up (to illustrate the issues > that appliance developers might face), I would be storing large files > (e.g., ISO's). But, some other developer/application might choose > to use the medium for smaller files -- or even smaller media capacity. > so right options. for smaller files newfs -m 0 -i -b 32768 -f 4096 -U this will mean longer fsck you may add -j if you like - soft updates journalling. > means little "mismatches" in configuration can have noticeable > impact on the end user (e.g., he opts for finer-grained management > and pays the price when a volume isn't properly dismounted, power > fail, etc.) depends on I/O style. On random I/O it will not have big impact. > >> newfs -m 0 -i 262144 -b 65536 -f 8192 -U /dev/yourdisk >> >> and it will be fast to fsck. >> > > From owner-freebsd-hackers@freebsd.org Sat Jul 11 00:39:05 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C591E3242 for ; Sat, 11 Jul 2015 00:39:05 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EBB7E51 for ; Sat, 11 Jul 2015 00:39:05 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by qkhu186 with SMTP id u186so217922028qkh.0 for ; Fri, 10 Jul 2015 17:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=date:from:to:subject:message-id:organization:mime-version :content-type:content-transfer-encoding; bh=MtuHR4+EMk8OYR11YkFTq1qtcxgCtFU3DDiArX3EWbA=; b=J1L/HRQVTDbfvF08C+00h4ANJs3tNz7a/zarO8X7310SP6lwp39a/Xp57FXfNtfEME +IpP5DjuWZmUDnAKSAuf4e4kE6N7GyhPLJXeFieoP0xZpVxlehZrFdJ9iY1vDdrenTWv rS3svIykaLY3PNLYfDYDSqYWvjvv+kTImT4yQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:organization :mime-version:content-type:content-transfer-encoding; bh=MtuHR4+EMk8OYR11YkFTq1qtcxgCtFU3DDiArX3EWbA=; b=hao/y7mnwSLgZBKHDVBuWQPa9TFVbG2JzZfO6uDnidEqGS/fk1iQbeVFBGCHH5pPgo 2dd7OGp2FouQAnd5L5JXo6sn3ZvONH3QaXFUPenVsdvgtCCGsMtkpxuHkyH6vFnaY4Fy 34KRzEtr1vMjQUpJUSaX9puAyEq/IZozVWKBpEWnLXySyODJ4q4sEt34iT4CIK3P3q09 DCDQC9uVo947Y86hq2yVEc9Fo8RTatMRQJDMpmWRa+lcr83H9SywGjkVGSz1kaGx9KTy 3QJSNTx6IFMBMeLer4Sbv95vbO3dg0q+qXZHSt3t2nRtpGX7AKu3knpXXlHrjbE0CqeN pNSg== X-Gm-Message-State: ALoCoQkmsu/ajxMvxBdd+iFMh26XC1Dr44ONIZS7n9ADZ8Civ3VS4tDi3KzNXAoZEZIlMCQ/D914 X-Received: by 10.55.40.34 with SMTP id o34mr25909512qkh.103.1436575144261; Fri, 10 Jul 2015 17:39:04 -0700 (PDT) Received: from Papi ([191.33.15.84]) by smtp.gmail.com with ESMTPSA id w126sm6509437qkw.32.2015.07.10.17.39.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2015 17:39:04 -0700 (PDT) Date: Fri, 10 Jul 2015 21:43:32 -0300 From: Mario Lobo To: FreeBSD-Hackers Mailing List Subject: Gigabyte 970A-UD3P and hwpstate problem Message-ID: <20150710214332.750f8c68@Papi> Organization: BSD X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 00:39:05 -0000 Hi; I just installed a Gigabyte 970A-UD3P mobo and updated BIOS to the latest version but the problem also showed with the previous version. Here is my amd64 10-STABLE setup: FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT 2015 amd64 CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0x1ebbfff Structured Extended Features=0x8 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=65536 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) [snip] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20150515/tbfadt-673) [snip] hpet0: iomem 0xfed00000-0xfed003ff on acpi0 [snip] amdtemp0: on hostb4 amdtemp0: CPU have TS: Temperature sensor amdtemp0: Found: Reported Temperature Control (RTC) amdtemp0: Found: Hardware Thermal Control (HTC) The problem: powerd: no cpufreq(4) support -- aborting: No such file or directory /etc/rc: WARNING: failed to start powerd Cool 'n' Quiet is enabled in BIOS but no hwpstate0 shows up on dmesg pciconf -lv | grep -A 3 none none0@pci0:0:20:0: class=0x0c0500 card=0x43851002 chip=0x43851002 rev=0x42 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SBx00 SMBus Controller' class = serial bus Everything else is accounted for. Tried evrey *smb*.ko from kernel but nothing happens kldstat Id Refs Address Size Name 1 42 0xffffffff80200000 16f7738 kernel 2 1 0xffffffff818f8000 f8c8 aio.ko 3 1 0xffffffff81908000 7678 amdtemp.ko 4 1 0xffffffff81910000 15080 fuse.ko 5 1 0xffffffff81926000 b62bf0 nvidia.ko 6 3 0xffffffff82489000 6cfb0 vboxdrv.ko 7 1 0xffffffff82611000 cae4 ext2fs.ko 8 1 0xffffffff8261e000 3b1c linprocfs.ko 9 1 0xffffffff82622000 3831b linux.ko 10 1 0xffffffff8265b000 1604 fdescfs.ko 11 1 0xffffffff8265d000 179e uhid.ko 12 1 0xffffffff8265f000 22e8 ums.ko 13 2 0xffffffff82662000 29b2 vboxnetflt.ko 14 2 0xffffffff82665000 9168 netgraph.ko 15 1 0xffffffff8266f000 1602 ng_ether.ko 16 1 0xffffffff82671000 3f64 vboxnetadp.ko sysctl -a | grep freq kern.timecounter.tc.TSC-low.frequency: 1607464785 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.i8254.frequency: 1193182 device cpufreq kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.LAPIC.frequency: 100466554 kern.acct_chkfreq: 15 net.inet.sctp.sack_freq: 2 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 800 machdep.tsc_freq: 3214929571 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 Would anyone have any suggestion that I could try? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] From owner-freebsd-hackers@freebsd.org Sat Jul 11 01:12:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19272378E for ; Sat, 11 Jul 2015 01:12:46 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from ftx-008-i766.relay.mailchannels.net (ftx-008-i766.relay.mailchannels.net [50.61.143.66]) by mx1.freebsd.org (Postfix) with ESMTP id 634B81FB1 for ; Sat, 11 Jul 2015 01:12:43 +0000 (UTC) (envelope-from mlobo@digiart.art.br) X-Sender-Id: hostmach|x-authuser|mlobo@digiart.art.br Received: from ariel.hmnoc.net (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 2B8D24052 for ; Sat, 11 Jul 2015 00:33:22 +0000 (UTC) X-Sender-Id: hostmach|x-authuser|mlobo@digiart.art.br Received: from ariel.hmnoc.net (ariel.hmnoc.net [10.251.34.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Sat, 11 Jul 2015 00:33:22 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostmach|x-authuser|mlobo@digiart.art.br X-MailChannels-Auth-Id: hostmach X-MC-Loop-Signature: 1436574802435:3897173264 X-MC-Ingress-Time: 1436574802435 Received: from [191.33.15.84] (port=62186 helo=Papi) by ariel.hmnoc.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZDijI-002iy9-GK for freebsd-hackers@freebsd.org; Fri, 10 Jul 2015 21:33:20 -0300 Date: Fri, 10 Jul 2015 21:37:52 -0300 From: Mario Lobo To: FreeBSD-Hackers Mailing List Subject: Gigabyte 970A-UD3P and hwpstate problem Message-ID: <20150710213752.473cb831@Papi> Organization: DigiArt X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AuthUser: mlobo@digiart.art.br X-Mailman-Approved-At: Sat, 11 Jul 2015 04:12:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 01:12:46 -0000 Hi; I just installed a Gigabyte 970A-UD3P mobo and updated BIOS to the latest version but the problem also showed with the previous version. Here is my amd64 10-STABLE setup: FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT 2015 amd64 CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0x1ebbfff Structured Extended Features=0x8 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=65536 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) [snip] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20150515/tbfadt-673) [snip] hpet0: iomem 0xfed00000-0xfed003ff on acpi0 The problem: powerd: no cpufreq(4) support -- aborting: No such file or directory /etc/rc: WARNING: failed to start powerd Cool 'n' Quiet is enabled in BIOS but no hwpstate0 shows up on dmesg pciconf -lv | grep -A 3 none none0@pci0:0:20:0: class=0x0c0500 card=0x43851002 chip=0x43851002 rev=0x42 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SBx00 SMBus Controller' class = serial bus Everything else is accounted for. Tried evrey *smb*.ko from kernel but nothing happens kldstat Id Refs Address Size Name 1 42 0xffffffff80200000 16f7738 kernel 2 1 0xffffffff818f8000 f8c8 aio.ko 3 1 0xffffffff81908000 7678 amdtemp.ko 4 1 0xffffffff81910000 15080 fuse.ko 5 1 0xffffffff81926000 b62bf0 nvidia.ko 6 3 0xffffffff82489000 6cfb0 vboxdrv.ko 7 1 0xffffffff82611000 cae4 ext2fs.ko 8 1 0xffffffff8261e000 3b1c linprocfs.ko 9 1 0xffffffff82622000 3831b linux.ko 10 1 0xffffffff8265b000 1604 fdescfs.ko 11 1 0xffffffff8265d000 179e uhid.ko 12 1 0xffffffff8265f000 22e8 ums.ko 13 2 0xffffffff82662000 29b2 vboxnetflt.ko 14 2 0xffffffff82665000 9168 netgraph.ko 15 1 0xffffffff8266f000 1602 ng_ether.ko 16 1 0xffffffff82671000 3f64 vboxnetadp.ko dmesg | grep amdtemp amdtemp0: on hostb4 amdtemp0: CPU have TS: Temperature sensor amdtemp0: Found: Reported Temperature Control (RTC) amdtemp0: Found: Hardware Thermal Control (HTC) sysctl -a | grep freq kern.timecounter.tc.TSC-low.frequency: 1607464785 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.i8254.frequency: 1193182 device cpufreq kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.LAPIC.frequency: 100466554 kern.acct_chkfreq: 15 net.inet.sctp.sack_freq: 2 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 800 machdep.tsc_freq: 3214929571 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 Would anyone have any suggestion that I could try? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] From owner-freebsd-hackers@freebsd.org Sat Jul 11 13:50:11 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14B619981B6 for ; Sat, 11 Jul 2015 13:50:11 +0000 (UTC) (envelope-from herbert@oslo.ath.cx) Received: from oslo.ath.cx (oslo.ath.cx [IPv6:2a01:4f8:200:42e4::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oslo.ath.cx", Issuer "oslo.ath.cx" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B52A21C3 for ; Sat, 11 Jul 2015 13:50:09 +0000 (UTC) (envelope-from herbert@oslo.ath.cx) Received: by oslo.ath.cx (OpenSMTPD) with ESMTP id 08280b3c for ; Sat, 11 Jul 2015 15:50:06 +0200 (CEST) Date: Sat, 11 Jul 2015 15:50:06 +0200 From: "Herbert J. Skuhra" To: freebsd-hackers@freebsd.org Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Message-ID: <20150711135006.GB41680@oslo.ath.cx> References: <20150710213752.473cb831@Papi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150710213752.473cb831@Papi> User-Agent: Mutt/1.5.23+100 (79cd2f34961d) (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 13:50:11 -0000 On Fri, Jul 10, 2015 at 09:37:52PM -0300, Mario Lobo wrote: > Hi; > > I just installed a Gigabyte 970A-UD3P mobo and updated BIOS to the > latest version but the problem also showed with the previous version. > > Here is my amd64 10-STABLE setup: > > FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT 2015 > amd64 > > CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 > Features=0x178bfbff > Features2=0x3e98320b > AMD Features=0x2e500800 > AMD > Features2=0x1ebbfff > Structured Extended Features=0x8 > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=65536 > TSC: P-state invariant, performance statistics > real memory = 17179869184 (16384 MB) > [snip] > ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero > address or length: 0x0000000000000000/0x1 (20150515/tbfadt-673) > [snip] > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > The problem: > > powerd: no cpufreq(4) support -- aborting: No such file or directory > /etc/rc: WARNING: failed to start powerd Could this be your problem: r276986 | nwhitehorn | 2015-01-11 18:10:07 +0100 (søn, 11 jan 2015) | 8 lines MFC r265329: Disable ACPI and P4TCC throttling by default, following discussion on freebsd-current. These CPU speed control techniques are usually unhelpful at best. For now, continue building the relevant code into GENERIC so that it can trivially be re-enabled at runtime if anyone wants it. Relnotes: yes % svnlite diff -c 276986 sys/amd64/conf/GENERIC.hints Index: sys/amd64/conf/GENERIC.hints =================================================================== --- sys/amd64/conf/GENERIC.hints (revision 276985) +++ sys/amd64/conf/GENERIC.hints (revision 276986) @@ -31,3 +31,5 @@ hint.attimer.0.port="0x40" hint.attimer.0.irq="0" hint.wbwd.0.at="isa" +hint.acpi_throttle.0.disabled="1" +hint.p4tcc.0.disabled="1" Does it work if your unset or remove those lines from /boot/device.hints? -- Herbert From owner-freebsd-hackers@freebsd.org Sat Jul 11 17:53:18 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC44A99822E for ; Sat, 11 Jul 2015 17:53:18 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D07912F2 for ; Sat, 11 Jul 2015 17:53:18 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by igrv9 with SMTP id v9so33009527igr.1 for ; Sat, 11 Jul 2015 10:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6859PY2vJs9S4ZpLRyq8HCWMmwanhZz6RY25fgL5Lvw=; b=F6Bdfyu38HiyaTdu1wNrpuJRvjmLZoZFxbHJVEy4prA9zpnPPUW1Tr+ygp+CIS2z86 E701Edb6a0maKdgUHmjJrs8eoX0x2uJfX/2lTaJKnqezSxooLUomJBYm2kuorlQuKqC0 ysk82ZLKk/NaZpXA6nSeqBE00yCd8hC+A7iPO8KVcruYAxJoTr6jurZqJBk3kKYaQhpG 2KQUdcElYW6MupHR8yiRfjLulTfv12+xpgungyd+gdD4rc9rAvPcpKVxU8XtRSP+DaBJ dyGMr665aGhpXpnPSt1Tl1VfJZLvMO15+vGbNIaTkWPlFJbjuZwYmK78Z1jTBKNrretx 5KUQ== MIME-Version: 1.0 X-Received: by 10.107.168.83 with SMTP id r80mr797159ioe.20.1436637197787; Sat, 11 Jul 2015 10:53:17 -0700 (PDT) Received: by 10.64.2.132 with HTTP; Sat, 11 Jul 2015 10:53:17 -0700 (PDT) Date: Sat, 11 Jul 2015 10:53:17 -0700 Message-ID: Subject: Re: format/newfs larger external consumer drives From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 17:53:18 -0000 > When building a filesystem (FFS) on these 1/2/3/4TB external USB > drives, any suggestions? E.g., changing block sizes? Cut into > multiple slices to make fsck's job easier (as well as *recovery*)? If the average filesize will be large, use large block/frag sizes. I use 64 KiB / 8 KiB. And reduce the number of inodes. I reduce inodes as much as newfs allows and there are still way too many. These 2 changes waste less space to filesystem overhead, and fsck runs a lot faster. If the disk has 4 KiB sectors, have the frag size be at least 4 KiB, and have partitions start at a multiple of 4 KiB. I recommend soft updates. When I started using su I magically stopped losing files. Have newfs label the filesystem(s). Then use /dev/ufs/mylabel in /etc/fstab and the filesystems will get mounted on the right places regardless of the disk being da0 or da1 or whatever. Swap can be labeled with glabel(8). Multiple slices? Consider the size of whatever media you'll be using for backups. Consider making a read-only partition, as it will not require fscking after a crash. Consider gpt. If you decide on one big filesystem you don't need any partitioning, just newfs the raw drive. USB specific stuff: There is an off by 1 sector problem, which will bite you if you switch a drive between using the sata-usb bridge and connecting the drive directly to a sata controller. I had to do a fair bit of hacking on the kernel to deal with this. (No, I don't have a nice clean patch to offer, sorry. Besides, I just plastered over the problem rather than hunting down and fixing the root cause, which is what really needs to be done.) I don't recall if it is off by one physical sector, or one logical sector. On a 4 KiB drive it *might* mess up having things be on 4K multiples. Word is that the disk manufacturers have changed the interface between the bridge and the drive on recent external drives, making it difficult-to-impossible to use the drive connected directly to a sata controller. :-( Some people believe that drives are binned, and the less-wonderful drives go into the externals. This could explain externals being less expensive, despite having more stuff (enclosure, bridge, wall-wart, cables). Given how high the failure rate of internal drives is, I hate to think how bad the externals must be. I have yet to see a [ps]ata-to-usb bridge that allows turning the disk's write cache off. Having the write cache turned off is kinda important. If anyone knows of a bridge that does allow turning the write cache off I'd love to hear about it, > Of course, anything external means the user could insert/remove it at > will -- which complicates how the system will deal with the resource. If the drive disappears with filesystem(s) mounted. the kernel might very well panic. There was a discussion of this problem recently. I thought that FUSE was suggested as a possible solution, but I can't find the discussion. This problem is not limited to users disconnecting usb drives without unmounting them. The problem happens all by itself with internal drives, as the drive, port multiplier, controller, or device driver decides to go out to lunch, and the kernel panics. This happens *far* too often, and *kills* reliability. We really need a solution for this. From owner-freebsd-hackers@freebsd.org Sat Jul 11 23:14:51 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2991998B0C for ; Sat, 11 Jul 2015 23:14:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2B63DE for ; Sat, 11 Jul 2015 23:14:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id t6BNEnME066991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Jul 2015 17:14:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id t6BNEnd1066988; Sat, 11 Jul 2015 17:14:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 11 Jul 2015 17:14:49 -0600 (MDT) From: Warren Block To: Dieter BSD cc: freebsd-hackers@freebsd.org Subject: Re: format/newfs larger external consumer drives In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 11 Jul 2015 17:14:49 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 23:14:52 -0000 On Sat, 11 Jul 2015, Dieter BSD wrote: > USB specific stuff: There is an off by 1 sector problem, which will > bite you if you switch a drive between using the sata-usb bridge > and connecting the drive directly to a sata controller. I had to > do a fair bit of hacking on the kernel to deal with this. (No, > I don't have a nice clean patch to offer, sorry. Besides, I just > plastered over the problem rather than hunting down and fixing the > root cause, which is what really needs to be done.) I don't recall > if it is off by one physical sector, or one logical sector. On a > 4 KiB drive it *might* mess up having things be on 4K multiples. > Word is that the disk manufacturers have changed the interface > between the bridge and the drive on recent external drives, making it > difficult-to-impossible to use the drive connected directly to a sata > controller. :-( This depends on the USB-SATA adapter. Some have bugs. Some give one less block that the drive's capacity by accident, some keep metadata in the last block. I've seen it, but only rarely with the USB-SATA adapters I've had.