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 > 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. 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 too. -Eric -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
