Go to the FreeLists Home Page Home Signup Help Login
 



[haiku-development] || [Date Prev] [04-2008 Date Index] [Date Next] || [Thread Prev] [04-2008 Thread Index] [Thread Next]

[haiku-development] Re: BFS and write back problems

  • From: Marcus Overhagen <marcusoverhagen@xxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 02 Apr 2008 22:03:45 +0200
Stephan Assmus schrieb:
Alexander G. M. Smith wrote:
dolgov wrote on Wed, 02 Apr 2008 13:19:19 +0300:
I thought about adding flush() in several places in code related to file transactions with ifdef BeOS [...]
We did that in the mail daemon replacement, after it had finished receiving a new batch of e-mail. Makes things a bit more reliable in BeOS R5, particularly if a mail fetch happened while debugging other crashy code. Though it does annoyingly spin up all sleeping hard drives with mounted file systems.

Actually, I think something like that is absolutely justified. It's the users email after all. I would go as far as add such behaviour to text editors in general. ;-)

I think that we need to be very careful with this. Applications shouldn't ever need to flush or sync. The kernel must handle this
automatically.

The kernel really needs to flush dirty data to the disc once the
system is "idle" after a disk operation (to be defined) for some
time (i.e. 500ms for removeable media, 3000 ms for permanent storage).

There is an issue with spinning down of harddisks. Usually I like my
harddisks to spin down after 20 minutes, but I read somewhere that
Linux had issues with that, because something is permanently writing
to the disk. In windows I observed something similar, windows writes
small data to disk every 20 seconds (or similar), but hdd spin down
works anyway.

I also think kernel should not execute the IDE/ATA/SCSI synchronize
cache command at regular intervals (unless the system is shut down), because that usually stalls the harddisk for a few seconds.

regards
Marcus





[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.