Booting Problem

[Ion-Mihai Tetcu]

On Tue, 03 Feb 2004 22:35:35 -0800
Rishi Chopra <rchopra at cal.berkeley.edu> wrote:

> Here's some questions:
> 
> If the server was idle (e.g. absolutely no processes running aside from 
> login shell and terminal and no disk access occurring) does it make 
> sense that the filesystem would have had a problem after being 
> improperly unmounted?

Each file system would be at least marked as being used, so fsck -p on
boot will print that and check them. Usually if the system is idle the
fs will be ok. But you have processes that are active in regard the fs,
even if not logged in (cron, ntp/ntpdate, syslog to name a few); /tmp
and /var usually have problems after an unclean shutdown.

Note two things about disks:

1. hw.ata.wc=0	disables write caching - bad for performance good for
integrity. When a disk does wc it holds data in its buffer and report it
as being written to the OS and this delay could go up to 60 seconds
(and even more) depending on the HDD and the load.

atacontrol cap <channel> <unit> should tell you the state of write
caching; on my system I have wc=0 but atacontrol shows it turned on, so
I might be wrong here or this is not supported on all HDDs.

2. kern.filedelay=30, kern.dirdelay=29, kern.metadelay=28 sets how often
the respective data is flushed ( synced(8) ) to disk when using
soft-updates; note the descending order, it is important. You might want
to decrease them, which will degrade performance, but could help a more
consistent fs in case of a crash.

When I test a new HDD, CDROM, kernel and world I usually decrease them
to 15,14,13 or even 10,9,8 until everything seems OK.
 
> Also, how long should an 'fsck' on a 500GB partition take?  It's been 
> running for almost 12 hours now, and the latest output is still "Phase 1 
> - check blocks and sizes"; is something wrong or is fsck still doing its 
> thing?

My largest was about 80G and it takes a few minutes with UDMA100 for a
small amount of errors, so I don't really know. But it depends on how
much the file system is damaged, the access speed of the disk/controller
and the processor/memory; I have the feeling the size - time progression
is not at all arithmetical.

As a note, if you don't really need a fs that big, use smaller
partitions and mount / symlink them where you need them where you need.
This will give you better chances in case of crash.


-- 
IOnut
Unregistered ;) FreeBSD user