[gentoo-user] Help running fsck on reiserfs lvm /var on production server?

[Tanstaafl]

Hi everyone,

What is best practice for doing this?

If I reboot in single user mode, will my lvm volumes (ie, /var) be
available for fsck'ing, or do I have to mount them first?

The current problem started after a different problem required me to do
a hard reset on the server - had to do with a mounted QNAP device being
unavailable when I initiated a reboot, and everything just hung.

Ever since I did this hard reset, the server hangs at unmounting /var.
I've let it sit there for at least an hour, and it never goes past that.

Then after I hard reset it, it fsck's /var partition again, maybe fixes
minor problems very quickly, and everything works fine until I have to
reboot or shutdown again.

This became a major problem this weekend when we had one extended power
outage (about 8 hours) yesterday evening, then another one (about 4
hours) this morning right after I got everything back up and running
from last nights outage.

Anyway, I need to do this this weened if at all possible, so...

Anyone have any pointers to detailed docs and or willing to hold my hand
through this a little?

Thanks,

Charles

[Alan McKinnon]

fsck'ing that filesystem should be no different from any other fsck - it
should find what it finds and fix what it can. The fs must be unmounted
of course which means you have to do it in single-user mode, or from
booting a rescue system (I prefer the second, I find it easier as none
of the production filesystems are required to be mounted).

fsck.resiserfs has several modes, IIRC there's --rebuild-tree or similar
that does an extensive checks but takes ages. I needed to do this 2 or 3
times when I was still using reiser. There's also an option to do not
writes if you want a sanity check first.

I'm not convinced a power outage broke the fs so that you now can't
umount it, I'm having a hard time imaging how that would happen. More
likely some other script file elsewhere is damaged and leaves files open
when the system wants to umount /var.

You have some options:

This requires considerable downtime, easily an hour or more. You can dd
/var somewhere to get a copy you can experiment on with another host. At
least you will then know how much downtime to schedule.

You should do a full check and repair on all filesystems to be 100% certain.

For the umount issues, that is trickier as you won't have log files in
/var after the fact. Any clues on the Alt-F12 console whilst shutting
down? Try configure your syslogger to send logs to another host, you
might be lucky enough to get some logs that way that describe what is
going on.
--
Alan McKinnon
alan.m...@gmail.com

[Tanstaafl]

On 2013-06-09 3:45 AM, Alan McKinnon <alan.m...@gmail.com> wrote:
> I'm not convinced a power outage broke the fs so that you now can't
> umount it, I'm having a hard time imaging how that would happen. More
> likely some other script file elsewhere is damaged and leaves files open
> when the system wants to umount /var.

Hmmm....

Admittedly, I don't reboot this system often, so maybe I'm
misremembering when the problem crept in.

Could it be the NFS mount that it is hanging on, and unmounting/var is
just that last thing showing on the screen?

I think I'll try manually unmounting that before rebooting the next time
I need to(need to update the kernel soon anyway)...

I do know the last few times this has happened, the NFS mount was
'unavailable' (the device had powered down without first unmounting it
from the server)...

I hope that is all it is...

Thanks Alan

[Alan McKinnon]

Ugh, NFS complicates things :-)

I have a similar thing with my notebook and NFS mounts at home, I often
forget to umount the NFS dirs, causing issues when I then go to work and
wake the machine up

If you have NFS in the mix, I'd certainly investigate that first before
getting into more complex things. Also check that your NFS and mount
stuff in /etc/init.d are doing the right thing in the right order with
both startup and shutdown


--
Alan McKinnon
alan.m...@gmail.com

[Neil Bothwick]

On Sun, 09 Jun 2013 17:14:57 +0200, Alan McKinnon wrote:

> I have a similar thing with my notebook and NFS mounts at home, I often
> forget to umount the NFS dirs, causing issues when I then go to work and
> wake the machine up

That's why I have my hibernate script unmount NFS shares and take the
network down before hibernating.


--
Neil Bothwick

WinErr 01B: Illegal error - You are not allowed to get this error.
Next time you will get a penalty for that.

[Tanstaafl]

Yep, that bugger was it...

umounted the NFS mount and the reboot went smooth as silk.

Now, to figure out why the NFS mount isn't unmounting properly during a
shutdown or reboot, but that will be another thread...

Thanks Alan!