On Fri, 25 Oct 2013 18:26:23 +0000 (UTC) "Artem S. Tashkinov" <t.ar...@lycos.com> wrote:
> Oct 25, 2013 05:26:45 PM, david wrote: > On Fri, 25 Oct 2013, NeilBrown wrote: > > > >> > >> What exactly is bothering you about this? The amount of memory used or the > >> time until data is flushed? > > > >actually, I think the problem is more the impact of the huge write later on. > > Exactly. And not being able to use applications which show you IO performance > like Midnight Commander. You might prefer to use "cp -a" but I cannot imagine > my life without being able to see the progress of a copying operation. With > the current > dirty cache there's no way to understand how you storage media actually > behaves. So fix Midnight Commander. If you want the copy to be actually finished when it says it is finished, then it needs to call 'fsync()' at the end. > > Hopefully this issue won't dissolve into obscurity and someone will actually > make > up a plan (and a patch) how to make dirty write cache behave in a sane manner > considering the fact that there are devices with very different write speeds > and > requirements. It'd be ever better, if I could specify dirty cache as a mount > option > (though sane defaults or semi-automatic values based on runtime estimates > won't hurt). > > Per device dirty cache seems like a nice idea, I, for one, would like to > disable it > altogether or make it an absolute minimum for things like USB flash drives - > because > I don't care about multithreaded performance or delayed allocation on such > devices - > I'm interested in my data reaching my USB stick ASAP - because it's how most > people > use them. > As has already been said, you can substantially disable the cache by tuning down various values in /proc/sys/vm/. Have you tried? NeilBrown
signature.asc
Description: PGP signature
