FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-28-2008, 12:22 PM
Ralf Ertzinger
 
Default RFC: Changing default filesystem parameters for power management reasons

Hi.

On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:

> Sounds like a good idea. It's also something i've been looking at a
> bit. Take e.g. something like xchat. If you enable logging there you
> basically keep your disc active all the time as xchat itself doesn't
> use a large internal cache to write the data out every X MB or so.

And why should it, honestly? Bufffering data ist the OSes job 99% of
the time. As long as xchat does not use fsync() after each write we
should be good.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 12:55 PM
Phil Knirsch
 
Default RFC: Changing default filesystem parameters for power management reasons

Ralf Ertzinger wrote:

Hi.

On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:


Sounds like a good idea. It's also something i've been looking at a
bit. Take e.g. something like xchat. If you enable logging there you
basically keep your disc active all the time as xchat itself doesn't

use a large internal cache to write the data out every X MB or so.


And why should it, honestly? Bufffering data ist the OSes job 99% of
the time. As long as xchat does not use fsync() after each write we
should be good.



Maybe i wasn't clear enough. But take for example the difference between
xchat and say, syslog. I'd be really unhappy if i'd loose 1 hour of
syslog data in the event of a system crash, but i couldn't care less if
i'd loose 1 hour of xchatlogs during that time. So it is in that case
application specific in a way, and the kernel can't (and shouldn't)
semantically know how important your data is that you write with it. And
currently you can either do a write() and let the data be flushed to
disk automatically by the kernel every dirty_writeback_centisecs or
directly use a flush() after your write to make sure data is written
immediately. So the only way an application can currently "delay" those
writes is by using internal buffers that fill up and get written once
they are full. And the difference between 1 write every minute due to
dirty_writeback_centisecs and 1 write every hour because the buffer
takes that long to get filled is quite large imo.


Regards, Phil

--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch@redhat.com>
Hauptstaetterstr. 58 | Web: http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd: You're only jealous cos the little penguins are talking to me.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 02:19 PM
Ralf Ertzinger
 
Default RFC: Changing default filesystem parameters for power management reasons

i.

On Fri, 28 Nov 2008 14:55:43 +0100, Phil Knirsch wrote:

> Maybe i wasn't clear enough. But take for example the difference
> between xchat and say, syslog. I'd be really unhappy if i'd loose 1
> hour of syslog data in the event of a system crash, but i couldn't
> care less if i'd loose 1 hour of xchatlogs during that time. So it is
> in that case application specific in a way, and the kernel can't (and
> shouldn't) semantically know how important your data is that you
> write with it.

Well, it does, in a way. If you absolutely want to have your data on
the disk you have to call flush(). If you do not you're at the mercy
of, well, whatever governs data storage these days. But that has
always been the case.

If the kernel default is to flush un-flush()-ed data only every hour
then, well, then that's that. Nobody ever guaranteed writes every
few seconds.

Retrofitting buffering into every application (or into glibc) does not
strike me as an elegant solution. Besides, it wastes memory.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-29-2008, 06:05 AM
"Dariusz J. Garbowski"
 
Default RFC: Changing default filesystem parameters for power management reasons

On 11/28/2008 06:55 AM, Phil Knirsch wrote:

Ralf Ertzinger wrote:

Hi.

On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:


Sounds like a good idea. It's also something i've been looking at a
bit. Take e.g. something like xchat. If you enable logging there you
basically keep your disc active all the time as xchat itself doesn't

use a large internal cache to write the data out every X MB or so.


And why should it, honestly? Bufffering data ist the OSes job 99% of
the time. As long as xchat does not use fsync() after each write we
should be good.



Maybe i wasn't clear enough. But take for example the difference
between xchat and say, syslog. I'd be really unhappy if i'd loose 1
hour of syslog data in the event of a system crash, but i couldn't
care less if i'd loose 1 hour of xchatlogs during that time.


Depends on the point of view -- take Joe The User who carries "Important
Conversation" of which he wants to have a log. He cares a lot that he
lost last hour of his xchat (or whatever he uses) logs. He quite likely
doesn't care about last hour of syslog messages (he may not even be
aware they exist in the first place)...


Regards,
Dariusz




__________________________________________________ _________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org