Re: high load, no bottleneck

2013-09-28 Thread Emmanuel Dreyfus
Thor Lancelot Simon wrote: > Do you mean "all these requests *could* be honored on first flush"? If > so, then yes, I agree. It could be done in a bold way by turning any VOP_FSYNC into a VFS_SYNC. Obviously it would be inappropriate in most situations, but when facing a huge amount of concuren

Re: high load, no bottleneck

2013-09-28 Thread Thor Lancelot Simon
On Sat, Sep 28, 2013 at 06:25:22AM +0200, Emmanuel Dreyfus wrote: > > Basically, if we have N pending VOP_FSYNC for a given filesystem, all > theses requests will be honoured on first flush, but they are serialized > and will be acknowledged one by one, with the cost of a useless flush > each time

Re: high load, no bottleneck

2013-09-28 Thread Emmanuel Dreyfus
Michael van Elst wrote: > >Basically, if we have N pending VOP_FSYNC for a given filesystem, all > >theses requests will be honoured on first flush, but they are serialized > >and will be acknowledged one by one, with the cost of a useless flush > >each time. Am I right? > > That should be trivi

Re: high load, no bottleneck

2013-09-28 Thread Michael van Elst
m...@netbsd.org (Emmanuel Dreyfus) writes: >Basically, if we have N pending VOP_FSYNC for a given filesystem, all >theses requests will be honoured on first flush, but they are serialized >and will be acknowledged one by one, with the cost of a useless flush >each time. Am I right? That should be

Re: high load, no bottleneck

2013-09-28 Thread Emmanuel Dreyfus
Robert Elz wrote: > incidentally, while the man page says that -o log and -o async > can't be used together, if they are, the result is a panic, rather > than a more graceful error message ... This could be a real problem on a system that allows unprivilegied users to mount thumb drives... --

Re: high load, no bottleneck

2013-09-28 Thread Robert Elz
Date:Sat, 28 Sep 2013 09:09:02 +0100 From:"Roland C. Dowdeswell" Message-ID: <20130928080902.gg4...@roofdrak.imrryr.org> | I thought quite some time ago that it probably makes sense for us | to make the installer mount everything async to extract the sets | beca

Re: com(4) and LSI bug workaround

2013-09-28 Thread Izumi Tsutsui
> Although the processing for this ARMADAXP was moved to com_mv.c, IIR of > com is reset by reading. That is, since IIR was read by mvuart_intr(), > IIR was not able to be correctly read by comintr(). > I would like to add the next member to com_softc, in order to solve this > problem. : > Please

Re: high load, no bottleneck

2013-09-28 Thread Roland C. Dowdeswell
On Sat, Sep 28, 2013 at 05:56:50PM +1000, matthew green wrote: > > > ps: I had been meaning to rant like this for some time, your message just > > provided the incentive today! > > :-) > > i will note that i'm also a fan of using -o async FFS mounts in > the right place. i just wouldn't do it f

re: high load, no bottleneck

2013-09-28 Thread matthew green
> ps: I had been meaning to rant like this for some time, your message just > provided the incentive today! :-) i will note that i'm also a fan of using -o async FFS mounts in the right place. i just wouldn't do it for a file server :-)

Re: high load, no bottleneck

2013-09-28 Thread Robert Elz
Date:Sat, 28 Sep 2013 14:24:32 +1000 From:matthew green Message-ID: <11701.1380342...@splode.eterna.com.au> | -o async is very dangerous. there's not even the vaguest | guarantee that even fsck can help you after a crash in | that case... All true, still it is