Re: fsck of big disk

2007-12-11 Thread Javier Martín Rueda

Valerio Daelli wrote:

Hi list

we have a freshly installed FreeBSD 6.2 machine with a gstriped external disk,
of 5.3Tb. The disk is composed of two slices of 2.6 Tb.
We are trying to have a (background) fsck of it but few hours later
since the start of the check
the host get unresponsive: it responds to ping but it doesn't let
login anyone, nor by ssh
nor by console.
  
What do you get if you press Control-T on the console when it is 
unresponsive?


When you do a background fsck there is a point at which a snapshot of 
the filesystem is taken, although I'd say that happens at the beginning 
of the check. The problem is that with 5.3 Tb, it may take quite a while 
to take the snapshot, and during that time the system blocks any process 
that tries to write to the filesystem. Maybe that's what you are 
experiencing.


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


Re: fsck of big disk

2007-12-11 Thread Valerio Daelli
Hi,
thanks a lot for your answer.

  we have a freshly installed FreeBSD 6.2 machine with a gstriped external 
  disk,
  of 5.3Tb. The disk is composed of two slices of 2.6 Tb.
  We are trying to have a (background) fsck of it but few hours later
  since the start of the check
  the host get unresponsive: it responds to ping but it doesn't let
  login anyone, nor by ssh
  nor by console.
 
 What do you get if you press Control-T on the console when it is
 unresponsive?

We are not able to login via console nor via ssh.
Pheraps you suggest me to press Control-T on the console even if I am not
logged on. I did not try, sorry.



 When you do a background fsck there is a point at which a snapshot of
 the filesystem is taken, although I'd say that happens at the beginning
 of the check. The problem is that with 5.3 Tb, it may take quite a while
 to take the snapshot, and during that time the system blocks any process
 that tries to write to the filesystem. Maybe that's what you are
 experiencing.


What you explained us sounds very interesting. But anyway we simply
solved by disabling background fsck on such a big partition. We had
panics and reboot
and we did not want to risk on a production host.
Bye

Valerio Daelli
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: fsck of big disk

2007-12-11 Thread Josh Paetzel
On Tuesday 11 December 2007 09:19:46 am Valerio Daelli wrote:
 Hi,
 thanks a lot for your answer.

   we have a freshly installed FreeBSD 6.2 machine with a gstriped
   external disk, of 5.3Tb. The disk is composed of two slices of 2.6 Tb.
   We are trying to have a (background) fsck of it but few hours later
   since the start of the check
   the host get unresponsive: it responds to ping but it doesn't let
   login anyone, nor by ssh
   nor by console.
 
  What do you get if you press Control-T on the console when it is
  unresponsive?

 We are not able to login via console nor via ssh.
 Pheraps you suggest me to press Control-T on the console even if I am not
 logged on. I did not try, sorry.

  When you do a background fsck there is a point at which a snapshot of
  the filesystem is taken, although I'd say that happens at the beginning
  of the check. The problem is that with 5.3 Tb, it may take quite a while
  to take the snapshot, and during that time the system blocks any process
  that tries to write to the filesystem. Maybe that's what you are
  experiencing.

 What you explained us sounds very interesting. But anyway we simply
 solved by disabling background fsck on such a big partition. We had
 panics and reboot
 and we did not want to risk on a production host.
 Bye

 Valerio Daelli

What you are probably running in to is memory starvation.  In my experience 
fsck on a moderately filled disk uses something on the order of 1 gig of RAM 
per TB of filesystem.  If you have this in an array with less than 4 gigs of 
RAM it's possible that it was just buried in swap and spending all it's time 
moving pages in and out as opposed to doing anything useful.


-- 
Thanks,

Josh Paetzel

PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB


signature.asc
Description: This is a digitally signed message part.