I can't claim to be 20 years in, but when we boot into rescue mode and run
fsck manually we only ever supply -y. All repairs are done and, as you say,
we worry about the consequences later.
-Mathew
"When you do things right, people won't be sure you've done anything at
all." - God; Futurama
"We'
I'm actually on a call right now and the use of forced fsck on reboot has
been brought up. However, in my experience this is a one-time event and
after reboot the "forced" file that makes it happen is removed.
I suppose I need to ensure this file is persistent.
-Mathew
"When you do things right,
Mathew Snyder
writes:
> Has anyone else dealt with a similar situation or at least have insight
> into steps we can take and tools we can implement to make our lives easier?
Nothing more than an anecdote but in practice we almost never have to
manually interact with RHEL fscks after an event
Mathew Snyder writes:
> How do your systems handle it? When the storage suddenly disappears and then
> reappears the OS isn't seeing that as an event that requires an automatic,
> online fsck.
When the OS or filesystem(s) lose their mind due to such an event we've
(in general) found no succe
On 31/10/13 01:51, Robert Hajime Lanning wrote:
hhmmm...
In my 20 years "fsck -y" was always "answer yes to all questions."
Agreed. -p (preen) was do any safe fixes (like assigning unowned disk
blocks to the free list) and -y (yes) was answer yes to all questions
and worry about the conseq
