nate wrote:
Ryan Babchishin said:
Is there any way for me to repair this on the fly? Even better - without
having to scan the whole array (since I know where the error is)?
there sure is! provided you don't mind even more curroption to your
filesystem tell fsck to force check. it will cause massive damage I bet :)
Ok, I'll get right on that!
if you do care about curroption, remount it read-only and do the fix,
people can still read the data but won't be able to change anything.
first, terminate all processes that are using the filesystem, then
mount /filesystem -o remount,ro
and run fsck on it.
Unfortunately, I don't really have that option in my environment.
it is unusual to have a filesystem curropt itself while mounted though
it's not totally unheard of, a few months ago I had my company's main
NFS server running solaris and UFS curropt part of it's filesystem, maybe
it's coincidence but the machine itself(ultra10) started beeping as well,
spent some time looking at the logs(syslog server) and discovered this,
took about 45 minutes to fsck the arrays(30GB & 100GB). I just told the
users, tough shit. If I let it continue you may lose yet more data, they
said fine and took a break. once the filesystems were repaired the
beeping stopped. never did find out if it was related, the ultra10 user
manual did not mention anything, and our on-site solaris certified admins
didn't know either.
I have no clue what caused this to happen either... it's quite unfortunate.
nate
Thanks Nate,
Ryan
--
Ryan Babchishin
System Administrator - x135
mailto:[EMAIL PROTECTED]
ePALS Classroom Exchange
Ph: 613.562.9847
Fax: 613.562.4768
http://www.epals.com/
The world's largest online classroom community -
connecting more than 4.5 million students and educators in 191 countries!
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
