On Thu, Nov 27, 2008 at 09:59:08AM -0600, Eric Sandeen wrote:
What are your plans to measure the results of these changes from
power &
performance perspectives? Also, tools to monitor what is causing disk
accesses might be good (see also Bug 454582 - Tracker bug for
over-eager apps that won't let disks spin down).
Power-wise, I have measuring equipment here. Performance is obviously
harder - I suspect synthetic benchmarks will get much the same
performance as usual, so that might be down to waiting to see if users
complain.
It would be nice to have the kernel export disk access via a socket or
something rather than the currently available debug option, which is to
dump to dmesg which then triggers log writes which triggers more
messages and fail occurs. I had a handwavy patch to do that, but we
probably want a good way of exposing that information to userspace.
Do you also have any plans for changing default disk spin-down times,
or
would that be left to bios settings? And if so, we should probably
monitor this for how it jives with the expected lifetime of a disk vs.
lifetime rating for spindown cycles.
Yes, the long-term plan involves allowing drive spindown. I'm hoping to
do this adaptively to let us avoid the spinup/down tendancies a static
timeout provides, but you're right that monitoring SMART information
would be a pretty important part of that. I lean towards offering it on
desktops and servers, but not enabled by default.
The original laptop mode kit included specific knowledge about some
filesystem tuning parameters (commit times etc), is that part of your
plan? Which filesystems will be recognized?
Mm. My recollection is that ext3 and xfs had easy to access tuning to
help in this respect. Changing the kernel defaults would be one option
there, or alternatively we could update fstab?
--
Matthew Garrett | mjg59(a)srcf.ucam.org