Re: RFC: Changing default filesystem parameters for power management reasons

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux