RFC: Changing default filesystem parameters for power management reasons

Phil Knirsch pknirsch at redhat.com
Fri Nov 28 13:55:43 UTC 2008


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.

Regards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.




More information about the fedora-devel-list mailing list