Matthew Garrett wrote:
> 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
> 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.
Yeah. Although you can tune things so that the block_dump stuff doesn't
go to /var/log/messages, but I'd played tricks in the past with saving
to ramdisks etc for this reason.
It'd also be nice if we could reliably query drives for their state, but
in the past the query itself has spun up some of my drives.
>> 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.
Sounds good. We don't want a "Fedora kills hard drives!" thread.
>> 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?
Yep, they do. xfs even has a bit of code specifically to work w/ laptop
mode. Looks like the current laptop tools do handle ext3 & xfs from a
cursory glance. Should probably make sure that ext4 is properly handled
fedora-devel-list mailing list