disk access seems unitask and ant-slow

[Nikola Pavlović]

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