RFC: Changing default filesystem parameters for power management reasons

Phil Knirsch pknirsch at redhat.com
Fri Nov 28 12:16:36 UTC 2008

Matthew Garrett wrote:
> I'd like F11 to be more useful for disk power management. This involves 
> tuning various parameters in order to reduce disk access. There are some 
> tradeoffs involved, so I'd like feedback before pushing much of this.

Great idea, i'm working quite a bit in that direction at them moment as 

> The first is relatime. I've just pushed Ingo's smarter relatime code 
> towards upstream again. In this configuration atime will only be updated 
> if the current atime is either older than ctime or mtime, or if the 
> current atime is more than a day in the past. The amount of time 
> required before atime is updated will be a tunable, and a norelatime 
> mount parameter will be available to mount filesystems without this 
> behaviour. This shouldn't affect the behaviour of any applications.

+1000. I've done a few tests here with my systems, and although the 
really bad offenders related to disk io are of course processes that do 
write access there are quite a few cases where read access happens which 
then has to update the atime and result in a write to the disc. :/

> The second is to increase the value of dirty_writeback_centisecs. This 
> will result in dirty data spending more time in memory before being 
> pushed out to disk. This is probably more controversial. The effect of 
> this is that a power interruption will potentially result in more data 
> being lost. It doesn't alter the behaviour of fsync(), so paranoid 
> applications will still get to ensure that their data is on disk. Of 
> course, it would also be helpful to stop applications generating dirty 
> pages where possible. This would obviously be reverted if the system 
> enters a critical power state.

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.

> Thirdly, I'd like to enable laptop mode by default. The effect of this 
> is that any access that goes to disk will trigger an opportunistic 
> flushing of dirty data shortly afterwards. To an extent this mitigates 
> the change to dirty_writeback_centisecs, but there's obviously still 
> some increased chance of data loss.

Agree as well, though i'm not sure if we should make it enabled by 
default as the risk of data loss in case of a system failure is quite 
high then.

> The combination of these features should result in (on average) fewer 
> disk accesses and so (on average) should provide better performance. 
> There's a chance that some usage patterns will fall foul of this and 
> lose performance, so if we do this I'd like to do it sufficiently early 
> in the cycle that we can get real-world feedback.

Sounds like a great idea and something i've been working on myself 
lately, too. I even went a bit further and thought about the idea if a 
combination of a monitoring backend and a tuning engine could provide an 
automatic adoption of the system to the current use. E.g. during daytime 
when a user works with his machine we would typically see quite a few 
reads and write all the time. Drive spindowns or other power saving 
features could during that time be reduced so that the user will have 
the best performance. During the night (in case he didn't turn of the 
machine) only very few read and even fewer write operations should 
happen, at which time the disk could then be powered down most of the 
time. And of course this can be extended to not only disk drivces but 
other tunable hardware components.

Reagards, 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