Has anyone mentioned turning off write caching?
hdparm -W 0 /dev/hda
This for me made the difference between rebuilding up to five system
disks per day (out of one hundred desktop workstations, and that was a
couple years ago), and rebuilding...none per day.
Users unplug and reset workstations without a second thought. Having
data on the drive not flushed is a killer.
Chris Wedgwood wrote:
> On Thu, Apr 01, 2004 at 07:42:48PM -0600, Dmitry Nikiforov wrote:
>
>
>>So technically the whole purpose of this is to provide faster
>>startup time after crash and not the consistency of data, correct?
>
>
> yes
>
> some fs' will journal all data though (reiserfs and ext3 can do this),
> but it often comes at a significant performance penalty for no real
> gain (and sometimes causes other problems like seeing old/stale data)
>
>
>>In case of Mozilla and its e-mail accounts - subdirectories and
>>files were there, but Mozilla didn't have the mailbox configuration,
>>so I've had to create it again and then copy the mailbox data files
>>over the newly created ones.
>
>
> i have seen this... usually it's configuration files being written to
> often, the metadat is logged but the datablocks aren't flushed. after
> a reboot you get nulls and mozilla either pukes or ignores the
> configuration (which is sensible)
>
> mozilla could be a little better about this for critical files IMO
>
>
>>As far as I can tell, they were being used at the moment of crash.
>
>
> if they were being written to then i would expect nulls, but not
> random data
>
>
>>Power outage, or me being impatient when I need to restart my system
>>(never caused any problems while I was using EXT3).
>
>
> "sync + reboot/poweroff" should be pretty safe (even if not
> recommended) --- fwiw i do it all the time and never have problems
>
>
>
>
>
>
|