From owner-freebsd-stable@FreeBSD.ORG Sun Feb 19 16:55:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEFE71065678 for ; Sun, 19 Feb 2012 16:55:54 +0000 (UTC) (envelope-from nzp@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB6A8FC12 for ; Sun, 19 Feb 2012 16:55:54 +0000 (UTC) Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 10A5C588FC for ; Sun, 19 Feb 2012 08:55:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nzp@fruiteater.riseup.net) with ESMTPSA id E4E955DB Date: Sun, 19 Feb 2012 17:55:49 +0100 From: Nikola =?utf-8?B?UGF2bG92acSH?= To: freebsd-stable@freebsd.org Message-ID: <20120219165549.GA33591@sputnjik.localdomain> Mail-Followup-To: freebsd-stable@freebsd.org References: <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> <4F3F8F0C.3000606@hm.net.br> <4F40231D.2080308@FreeBSD.org> <4F40F8CA.4030705@hm.net.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F40F8CA.4030705@hm.net.br> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.3 at mx1 X-Virus-Status: Clean Subject: Re: disk access seems unitask and ant-slow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 16:55:54 -0000 On Sun, Feb 19, 2012 at 11:27:38AM -0200, H wrote: > Doug Barton wrote: > > First, please don't start a new thread by replying to an existing > > message and changing the subject line. That screws up threading > > for those of us who use threaded mail readers, and may cause your > > message to be ignored. > > > > On 02/18/2012 03:44, H wrote: > > > >> Hi > > > >> I have 9-Stable on one partition of my SATAII disk, with kde4, to > >> be sure I compiled yesterday sources world and kernel > > > >> happens that any secondary task with diskaccess is so very slow > >> that it is inacceptable > > > >> for example, compiling firefox and then trying to open an image > >> with gimp, I am sitting here for over 5 minutes and the open > >> image dialog still do not show the directory content ..., same > >> with dolphin or any other diskaccess > > > > Please try compiling a custom kernel with the 4BSD scheduler > > instead of SCHED_ULE and see if that helps. > > > > > > > Hi > > no idea what you referring to in your "top post" but since we are both > "newcomers" here we're still learning and skip it ok :) > If no one points out your mistake how are you going to learn? :) He is referring to the fact that you started your thread by replying to an existing one, namely "disk devices speed is ugly". By doing that you made your initial message's headers to refer to that thread, which makes threading mail clients sort it to that thread. This is not "just" a cosmetic or netiquette problem since people might use "delete-thread" on previous thread deleting your unrelated message in the process, thus your message gets ignored (unintentionally). > now, 4FBSD really changed for me the face of the system, generally, I > have much better response, thank you for the hint, it is ok now > > can you tell if it is worth checking this out on amd64 servers also? > > > but seems that the principal delay came as present from a pkg > maintainer who dares piping shit into the system config without > telling or asking: > > echo 'fusefs_enable="YES"' >> ${LOADER_CONFIG} > > fusefs-kmod I'm talking about, where LOADER_CONF is rc.conf for his script > You told it to do that yourself. From the Makefile: OPTIONS= AUTOSETUP "Automatic global config file setup" off You see, off by default. I suggest you should be careful to not accuse others of "piping shit" into something before you make sure you're not doing it yourself. And if changing the scheduler fixed the problem how did you suddenly jump to the conclusion that the problem is in enabling FUSE at boot time? -- For every credibility gap, there is a gullibility fill. -- R. Clopton