Re: fsck and dump freeze freebsd. any ideas?

2009-07-29 Thread DA Forsyth
On 29 Jul 2009 , freebsd-questions-requ...@freebsd.org entreated 
about
 freebsd-questions Digest, Vol 269, Issue 6:

   After one of the last crashes, the system would lock up a short time
 after rebooting. I found the problem caused by background fsck locking
 up the system. I took the partition out of the startup check for now.
 I 'think' I was installing a port during the last crash, but it has
 been a while. I performed a fsck and a dump (to /dev/null) confirming
 that both do crash the freebsd 7.2 and 6.2 (which I booted off of a
 separate drive). A tar to /dev/null did run successfully, but I recall
 reading that that is not a recommended way to backup/move a
 filesystem. The /usr partition where it causes trouble is in a raid5
 geom_vinum three drive array. I did not yet have the array rebuild the

My experience has been that dump *with snapshot* of a live filesystem 
will crash if the filesystem is 'large'.  MY solution is to umount 
the partition.  This happens with my 800GB /home which is part of a 4 
drive raid5 array (ar driver with hardware setup).  It used to happen 
with the previous 320GB mirror array too, just with /home which is 
the biggest partition.   This is one reason I moved away from tape 
backup to a secondary server full of harddrives as backup target, the 
tape took far too long with /home unmounted and users were affected.

As for the fsck crashing, I'm lost.  Maybe a faulty drive?  




--
   DA Fo rsythNetwork Supervisor
Principal Technical Officer -- Institute for Water Research
http://www.ru.ac.za/institutes/iwr/


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


fsck and dump freeze freebsd. any ideas?

2009-07-29 Thread Edward Sanford Sutton, III
  The smartctl tests on the three drives came back saying they were checked 
100% without error; bad sectors have always caused an error and an aborted 
scan at the point of trouble for me in the past.
  I 'thought' I recalled seeing a panic along the lines of ffs_free or 
something related to free blocks or something at one point; maybe that was an 
error with fsck on the live system when manually ran. I will try to 
reproduce. Otherwise I do not know that fsck crashes; the entire system 
locks. I will see if I can reproduce the problem as a panic.
  There were some errors fsck seems to think it cleaned. A couple still exist 
indicating wrong counts about '12 should be 4' or '4 should be 0' type stuff. 
One error had a ridiculously large seven digit or so number that fsck said 
should be reduced. I had made a many terabyte file with a dd write to the end 
of a file of the largest size it would let me create and have since deleted 
the file; maybe that was what the reference was to. After fixing some errors, 
the fsck still causes a freeze and at what seems to be about the same point.
  The filesystem was unmounted for the dump and fsck has been attempted both 
mounted and unmounted. The filesystem has (ufs, NFS exported, local, 
soft-updates) reported for features by mount under normal operation.
  The freeze with dump did occur during a snapshot creation, which I found I 
cannot kill with a -9 (kill attempted minutes before the crash which still 
would not stop the creation).
  The powerdown question is more for how to handle an unsafe powerdown/crash 
on an active system. If I need to read from a partition, would read only 
leave it completely clean? Is there a way to operate on a file system which 
is treated as more of a ramdisk of changes and keeps the real partition 
unmodified (giving results like Faronics deepfreeze software or qemu disks in 
snapshot mode)?
  Would a zfs mirror configuration handle the unexpected crash/powerdown? 
Would it just report and fix the corruption, mention what files/structures 
weror impacted, offer restore of that data from a recent snapshot, or just 
say it is time to restore from a backup?
  Thanks again for the feedback,
Ed Sutton
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


fsck and dump freeze freebsd. any ideas?

2009-07-28 Thread Edward Sanford Sutton, III
  After one of the last crashes, the system would lock up a short time after 
rebooting. I found the problem caused by background fsck locking up the 
system. I took the partition out of the startup check for now. I 'think' I 
was installing a port during the last crash, but it has been a while.
  I performed a fsck and a dump (to /dev/null) confirming that both do crash 
the freebsd 7.2 and 6.2 (which I booted off of a separate drive). A tar 
to /dev/null did run successfully, but I recall reading that that is not a 
recommended way to backup/move a filesystem. The /usr partition where it 
causes trouble is in a raid5 geom_vinum three drive array. I did not yet have 
the array rebuild the parity nor do I know if there is any 
advantage/disadvantage in doing so (for this problem). I ran a long test on 
the drives using smartctl (which is a safer surface check than dd because 1 
bad sector on my promise controller will cause a panic; I have an unrelated 
drive with a corrupted sector if the promise controller dirver has an 
interested maintainer.)
  When running fsck, it is somewhere within phase 1 when it crashes. I ran a 
truss run of fsck with -aedD and snapped a photo of my screen when it crashed 
which I can type up if it is of any use. At the time of freebsd freezing, the 
hard drive activity light goes from a faint flicker to on solid for about a 
second and then goes out. The system is completely unresponsive where it 
locks showing no sign of activity that I have been able to notice.
  I imagine the recommendation is start over, but before I do (and likely just 
try a tar backup/restore), are there any other suggestions and questions 
before I blow away the problem? It would be nice for freebsd users to not be 
able to run into such a problem.
  As a final question, is there any safe way to crash freebsd (or pull system 
power) without a risk of filesystem corruption?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: fsck and dump freeze freebsd. any ideas?

2009-07-28 Thread Polytropon
On Tue, 28 Jul 2009 14:07:13 -0700, Edward Sanford Sutton, III 
mirror...@cox.net wrote:
   As a final question, is there any safe way to crash freebsd (or pull system 
 power) without a risk of filesystem corruption?

An easy way is to go into single user mode and umount all the
partitions, then press Reset or Power off. Most cases of file system
corruption on hard reset or power loss are often repaired well by
the fsck program. (I had system crashes due to defective USB sticks
and never had file system corruption after a successful fsck run.
Note that I did fsck in the foreground.)

If you cannot umount disks, run sync three or four times and wait
a little while. This is not as good as umounting disks, and quite
useless if the system is active (in terms of file I/O).


-- 
Polytropon
From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: fsck and dump freeze freebsd. any ideas?

2009-07-28 Thread Adam Vande More
On Tue, Jul 28, 2009 at 4:16 PM, Polytropon free...@edvax.de wrote:

 On Tue, 28 Jul 2009 14:07:13 -0700, Edward Sanford Sutton, III 
 mirror...@cox.net wrote:
As a final question, is there any safe way to crash freebsd (or pull
 system
  power) without a risk of filesystem corruption?

 An easy way is to go into single user mode and umount all the
 partitions, then press Reset or Power off. Most cases of file system
 corruption on hard reset or power loss are often repaired well by
 the fsck program. (I had system crashes due to defective USB sticks
 and never had file system corruption after a successful fsck run.
 Note that I did fsck in the foreground.)

 If you cannot umount disks, run sync three or four times and wait
 a little while. This is not as good as umounting disks, and quite
 useless if the system is active (in terms of file I/O).


 --
 Polytropon
 From Magdeburg, Germany
 Happy FreeBSD user since 4.0
 Andra moi ennepe, Mousa, ...


I've had fs corruption after a successful fsck runs, sometimes multiples are
needed.  I think after 2 consecutive runs it's as good as it's going to get,
but I could be wrong more may be helpful.  This is a rare occurrence in my
experience.

-- 
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org