Re: File system corruption upon reboot with gmirror
Nejc S wrote: Hello, Afaic this only happens on a power loss or otherwise unclean shutdown but I used the reboot command from the shell (in a background (sleep Don't use reboot, use shutdown -r now. I also had the same problem once (had to get physical access to the box to fix it) and it was because of the reboot. Thanks. I guess I'll use shutdown -r now then in future. If it still happens then I'll post again... Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File system corruption upon reboot with gmirror
Gunther Mayer wrote:
Don't use reboot, use shutdown -r now. I also had the same problem
once
(had to get physical access to the box to fix it) and it was because
of
the reboot.
Thanks. I guess I'll use shutdown -r now then in future. If it still
happens then I'll post again...
What's this stuff? shutdown -r is implemented using reboot.
if (doreboot) {
execle(_PATH_REBOOT, reboot, -l, nosync,
^^^
(char *)NULL, empty_environ);
syslog(LOG_ERR, shutdown: can't exec %s: %m.,
_PATH_REBOOT);
warn(_PATH_REBOOT);
}
--
Michel TALON
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File system corruption upon reboot with gmirror
On Thu, Sep 11, 2008 at 04:12:09PM +0200, Michel Talon wrote: Gunther Mayer wrote: Don't use reboot, use shutdown -r now. I also had the same problem once (had to get physical access to the box to fix it) and it was because of the reboot. Thanks. I guess I'll use shutdown -r now then in future. If it still happens then I'll post again... What's this stuff? shutdown -r is implemented using reboot. Only when you give it -o. Otherwise it sends a signal to init, and init manages the shutdown.The code you quote is only run if -o is given. -- Shenanigans! Shenanigans!Best of 3! -- Flash ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File system corruption upon reboot with gmirror
Mike Bristow said:
What's this stuff? shutdown -r is implemented using reboot.
Only when you give it -o. Otherwise it sends a signal to init,
and init manages the shutdown.The code you quote is only
run if -o is given
But the code is init implementing reboot is the same as in the commande
reboot and uses the call reboot(2)
/usr/src/sbin/init/init.c line 643
if (Reboot) {
/* Instead of going single user, let's reboot the
* machine */
sync();
alarm(2);
pause();
reboot(howto);
_exit(0);
}
Note the reboot(howto) which is exactly the same as in the command
reboot. If there are differences it may be in the number of sync(),
pause() and so on issued, i have not checked, but i would be surprised
that there is any significative difference between the several ways of
rebooting.
--
Michel TALON
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File system corruption upon reboot with gmirror
Hello, Afaic this only happens on a power loss or otherwise unclean shutdown but I used the reboot command from the shell (in a background (sleep Don't use reboot, use shutdown -r now. I also had the same problem once (had to get physical access to the box to fix it) and it was because of the reboot. Bye, Nejc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
File system corruption upon reboot with gmirror
Hi guys, I recently updated my FreeBSD 6.3 on our server to the latest patch with freebsd-update and seeing that it involved some kernel patches on 64bit I had to reboot. So I carried out an automated reboot during low-load times but alas, the box never came back up again. After gaining physical access to the console I realised that it choked on the unclean /usr file system and was unable to proceed as the automatic fsck failed, prompting for an emergency shell. An fsck -y followed by a reboot sorted out the issue but it caused a good 1.5h of total downtime which should have been only 4min. So, why was the file system unclean even though I rebooted properly? Afaic this only happens on a power loss or otherwise unclean shutdown but I used the reboot command from the shell (in a background (sleep 21600; reboot) but that shouldn't matter). So surely it would have flushed all the buffers in time? Or is the standard 60 seconds it waits maximum for kernel tasks to finish upon reboot too low and it couldn't finish in time (in which case, how do I change that?)? To give you a bit more background, I run a gmirror(8) RAID 1 over two disks whose health seems intact (zero bad gmirror log entries): $ mount /dev/mirror/gm0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) Gunther ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
