Freebsd filesystem ( hard reboot )

[Barnaby Scott]

On Thu, December 6, 2007 4:42 pm, Randy Ramsdell wrote:
> Vince wrote:
>
>> Randy Ramsdell wrote:
>>
>>
>>> We started using FreeBSD for some network monitoring, but have found
>>> that a hard reboot forces us to answer filesytem questions on boot. Is
>>>  there a way to mount each filesystem without this? Or how can we use
>>>  FreeBSD in a remote location without needing to intervene in
>>> situatutions like this?
>>>
>>>
>>
>> This is unusual in my experience, part of the charm of FreeBSD for me
>> is how rarely I have had to interact with fsck thanks to the whole
>> background fsck thing. What version of FreeBSD are you using?
>>
>> Assuming a 5.x or later since you say you've started to use FreeBSD.
>>
>>
>>
> I am fairly sure it is v6.2
>
>> What is the value of background_fsck in /etc/rc.conf ?
>>
>>
>>
> This isn't set. Was is supposed to be? So far, I have only installed
> applications we need. And everything seem fine except the reboot issue.
> This will be an offsite system so I do not want human intervention on
> boot for power outages or hard reboots.
>> You can also try setting fsck_y_enable="YES" in rc.conf (this will do
>> fsck -y if the initial preen fails.)
>>
>>
> I will use this. Do you mean by try, that this will work? I assume so.
>
>
> Thanks Vince!
>

I should first say that I am pretty new to all this, so my response is
intended as a question as much as an answer!

My understanding from the reading I have done is that in a situation like
this where power outages are a danger (and presuably having the UPS signal
the server to shut down gracefully is not practical), you need to make the
file system as robust as possible in the first place, rather than rely on
fsck -y after the event. Doesn't fsck -y rather sweep potential problems
under the carpet?

First step surely is to *disable* write caching if you have drives that
are doing it?

Then consider mounting the file system synchronously. Mind you, I don't
know what the scale of the performance loss would be, and whether anyone
does this nowadays!

As I say, don't rely on my knowledge, but I was prompted to write by your
latching on to a suggestion that was probably not intended to be the whole
solution.

Barnaby Scott