Bug 454582

Summary:	Tracker bug for over-eager apps that won't let disks spin down
Product:	[Fedora] Fedora	Reporter:	Eric Sandeen <esandeen>
Component:	distribution	Assignee:	Václav Pavlín <vpavlin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	amlau, arjan, dcantrell, eteo, jannes.faber, mclasen, rtc, rvokal, sluskyb, torsten
Target Milestone:	---	Keywords:	Tracking
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-05 13:28:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	454574, 454576, 454581, 457155, 466601, 467803, 467804, 468434, 479192, 488268, 491552, 507963, 515037, 521952, 919311
Bug Blocks:	484668

Description Eric Sandeen 2008-07-09 03:57:50 UTC

Apps which habitually write, and rewrite, and rewrite again the same file over
and over without changes prevent disks from spinning down and thus impact power
use, battery life, etc.

One easy-ish way to find these on an otherwise idle system is:

# sysctl -w vm.block_dump=1
# while true; do sleep 10; date; dmesg -c; done

and see for example:

Tue Jul  8 22:53:35 CDT 2008
ypbind(3241): dirtied inode 33391 (redhat.com.1) on sda11
ypbind(3241): dirtied inode 37462 (redhat.com.2) on sda11

Comment 1 Eric Sandeen 2008-07-09 04:03:18 UTC

actually:

# while true; do sleep 10; date; dmesg -c | grep -v "kjournald\|pdflush"; done

kjournald, pdflush are reactionary...

Comment 2 Eric Sandeen 2009-03-22 22:29:52 UTC

Oh, just a note; now that relatime isn't on by default anymore, you'd want your root fs mounted noatime for the above test to be useful.

Comment 3 Mace Moneta 2009-03-24 21:04:38 UTC

Should bug #491552 be added to this list?

Comment 4 Phil Knirsch 2009-03-25 12:57:47 UTC

Sounds like a good candidate, yes.

Thanks & regards, Phil

Comment 5 David Zeuthen 2009-04-07 20:31:45 UTC

Note that recent udev versions (udev >= 139) will cause a 'change' uevent *every* time a block device opened for writing (e.g. O_WRONLY or O_RDRW) is closed. This 'change' uevent is going to cause vol_id and other tools that investigate the block device to run. Some of the time the sectors needed for vol_id (typically at the beginning and the end of the disk) will be in the page cache but sometimes they are not.

I'd like to stress that this behavior is a *feature*, not a bug: it's how we keep e.g. the desktop icons in sync with whatever you do to a device on the command line (e.g. run mkfs). It's also how we keep persistent device symlinks e.g. /dev/disk/* in sync.

Anyway, what this means is that one important goal in avoiding disk spin downs is to ensure that apps use O_RDONLY as much as possible. As it turns out, a whole bunch of apps get this wrong and open the device with O_RDRW just because they can.

Comment 6 Eric Sandeen 2009-07-17 19:39:45 UTC

David, interesting.  (just caught that latest comment) - can udev report who opened it RDWR?

thanks,
-Eric

Comment 7 Peter Backes 2009-07-17 20:24:52 UTC

Can someone please merge the following bugs/mark two of them as duplicate? They are all the same issue (hdparm opening device with O_RDRW instead of O_RDONLY):

bug #494711 -  Kernel prevents drive spinning down
bug #507963 -  hdparm can't spin down my pata drives
bug #511936 -  hdparm / -C wakes up disk?

In addition, the first is incorrectly filed as a kernel bug.

It's trivial to fix BTW (just needs updating to current upstream release).

Comment 8 Jannes Faber 2009-08-01 00:49:19 UTC

Just added Bug #515037, I think it belongs in the "depends on" list here.

Thanks

Comment 9 Eric Sandeen 2009-08-01 02:36:31 UTC

Jannes, seems so, I've added it (I don't see it on my system but we'll let the other bug sort that out).

Comment 12 Radek Vokál 2016-11-05 13:28:11 UTC

Closing, seems all the tracking bugs are closed by now ..