RFC: Changing default filesystem parameters for power management reasons

[Simo Sorce]

On Fri, 2008-11-28 at 14:55 +0100, Phil Knirsch wrote:
> Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:
> > 
> >> Sounds like a good idea. It's also something i've been looking at a
> >> bit. Take e.g. something like xchat. If you enable logging there you 
> >> basically keep your disc active all the time as xchat itself doesn't
> >> use a large internal cache to write the data out every X MB or so.
> > 
> > And why should it, honestly? Bufffering data ist the OSes job 99% of
> > the time. As long as xchat does not use fsync() after each write we
> > should be good.
> > 
> 
> Maybe i wasn't clear enough. But take for example the difference between 
> xchat and say, syslog. I'd be really unhappy if i'd loose 1 hour of 
> syslog data in the event of a system crash, but i couldn't care less if 
> i'd loose 1 hour of xchatlogs during that time. So it is in that case 
> application specific in a way, and the kernel can't (and shouldn't) 
> semantically know how important your data is that you write with it. And 
> currently you can either do a write() and let the data be flushed to 
> disk automatically by the kernel every dirty_writeback_centisecs or 
> directly use a flush() after your write to make sure data is written 
> immediately. So the only way an application can currently "delay" those 
> writes is by using internal buffers that fill up and get written once 
> they are full. And the difference between 1 write every minute due to 
> dirty_writeback_centisecs and 1 write every hour because the buffer 
> takes that long to get filled is quite large imo.

Oh, but the kernel knows, the write() semantics clearly state that if
you want to make sure data is on disk you call flush(). If you don't
call flush() the kernel can delay flushing to disk indefinitely. So the
kernel have a very well defined way to know what apps want.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York