I don't bother changing the setting for local disks as it is
usually
pretty quick to scan them. You must have a pretty big and/or
slow
file system for fsck to take 2+ hours.
nate
On Thu, Feb 18, 2010 at 10:12 AM, Henry Ritzlmayr fedora-l...@rc0.atwrote:
I don't bother changing the setting for local disks as it is
usually
pretty quick to scan them. You must have a pretty big and/or
slow
file system for fsck to take 2+
On 02/18/2010 09:54 AM, Rudi Ahlers wrote:
...
But, how does one get past this? I know we need to reboot from time to time,
but more than often it's (preferably) not sooner than 6 - 10 months, so fsck
will run.
Turn off automatic fsck with tune2fs -i 0 -c 0 and instead
do a manual fsck (reboot
Rudi Ahlers wrote on Thu, 18 Feb 2010 10:54:11 +0200:
The server booted up, ran fsck, then each VM, as it booted up ran fsck as
well - which just slowed down the whole process since there's a 5 minute
delay in starting each VM.
Why would you autostart a VM only every 5 minutes? Or did you
At Thu, 18 Feb 2010 10:07:27 +0100 CentOS mailing list centos@centos.org
wrote:
On 02/18/2010 09:54 AM, Rudi Ahlers wrote:
...
But, how does one get past this? I know we need to reboot from time to time,
but more than often it's (preferably) not sooner than 6 - 10 months, so fsck
will
On Thu, 18 Feb 2010, Kai Schaetzl wrote:
Rudi Ahlers wrote on Thu, 18 Feb 2010 10:54:11 +0200:
The server booted up, ran fsck, then each VM, as it booted up ran fsck as
well - which just slowed down the whole process since there's a 5 minute
delay in starting each VM.
Why would you
On Thu, Feb 18, 2010 at 10:12 AM, Henry Ritzlmayr
fedora-l...@rc0.atwrote:
nate wrote:
I don't bother changing the setting for local disks as it is
usually pretty quick to scan them. You must have a pretty big
and/or slow file system for fsck to take 2+ hours.
--- Original message ---
From: m.r...@5-cent.us
Sent: 18.2.'10, 18:21
On Thu, Feb 18, 2010 at 10:12 AM, Henry Ritzlmayr
fedora-l...@rc0.atwrote:
nate wrote:
I don't bother changing the setting for local disks as it is
usually pretty quick to scan them. You
Timo wrote:
--- Original message ---
From: m.r...@5-cent.us
Sent: 18.2.'10, 18:21
On Thu, Feb 18, 2010 at 10:12 AM, Henry Ritzlmayr
fedora-l...@rc0.atwrote:
nate wrote:
I don't bother changing the setting for local disks as it is
usually pretty quick to scan them. You
--- Original message ---
From: m.r...@5-cent.us
To: centos@centos.org
Sent: 18.2.'10, 18:55
Timo wrote:
--- Original message ---
From: m.r...@5-cent.us
Sent: 18.2.'10, 18:21
On Thu, Feb 18, 2010 at 10:12 AM, Henry Ritzlmayr
fedora-l...@rc0.atwrote:
nate wrote:
Timo wrote:
From: m.r...@5-cent.us
Sent: 18.2.'10, 18:55
Timo wrote:
--- Original message ---
From: m.r...@5-cent.us
Sent: 18.2.'10, 18:21
On Thu, Feb 18, 2010 at 10:12 AM, Henry Ritzlmayr
fedora-l...@rc0.atwrote:
nate wrote:
snip
a) I'm talking about
work;
..my systems
m.r...@5-cent.us wrote:
It was dumping large amounts of data into his home directory... which was
NFS mounted from the server I needed to reboot.
That's why I like HA clusters, our NFS cluster runs on top of
CentOS, and if we needed to reboot a node it would have minimal
impact, the other
nate wrote:
m.r...@5-cent.us wrote:
It was dumping large amounts of data into his home directory... which
was
NFS mounted from the server I needed to reboot.
That's why I like HA clusters, our NFS cluster runs on top of
CentOS, and if we needed to reboot a node it would have minimal
On Wed, Jan 6, 2010 at 9:17 PM, Robert Heller hel...@deepsoft.com wrote:
There are two metrics used: number of times a FS is mounted and number
of days since last fsck/mount. For machines that don't get rebooted
often (eg servers) the 'number of times a FS is mounted' almost never
kicks
Rudi Ahlers wrote:
Is it absolutely necessary to run this on servers? Especially since they
don't reboot often, but when they do it takes ages for fsck to finish -
which on web servers causes extra unwanted downtime.
Or is there a way to run fsck with the server running? I know it's a bad
On Thu, Feb 18, 2010 at 2:13 AM, nate cen...@linuxpowered.net wrote:
Rudi Ahlers wrote:
Is it absolutely necessary to run this on servers? Especially since
they
don't reboot often, but when they do it takes ages for fsck to finish -
which on web servers causes extra unwanted downtime.
Hey folks,
I searched the list archives and found this :
echo AUTOFSCK_TIMEOUT=5 /etc/sysconfig/autofsck
echo AUTOFSCK_DEF_CHECK=yes /etc/sysconfig/autofsck
http://lists.centos.org/pipermail/centos/2006-November/029837.html
Alan McKay wrote:
I want to do a reboot of a couple of systems during our maintenance
window and fsck them, but would rather try it from home first and not
go to the data center. Then of course rush there like a madman if
they don't come back up :-)
No out of band management?
nate
On 1/6/2010 11:19 AM, Alan McKay wrote:
Hey folks,
I searched the list archives and found this :
echo AUTOFSCK_TIMEOUT=5 /etc/sysconfig/autofsck
echo AUTOFSCK_DEF_CHECK=yes /etc/sysconfig/autofsck
http://lists.centos.org/pipermail/centos/2006-November/029837.html
Hey folks,
I searched the list archives and found this :
echo AUTOFSCK_TIMEOUT=5 /etc/sysconfig/autofsck
echo AUTOFSCK_DEF_CHECK=yes /etc/sysconfig/autofsck
http://lists.centos.org/pipermail/centos/2006-November/029837.html
On Wed, Jan 6, 2010 at 12:34 PM, nate cen...@linuxpowered.net wrote:
Alan McKay wrote:
I want to do a reboot of a couple of systems during our maintenance
window and fsck them, but would rather try it from home first and not
go to the data center. Then of course rush there like a madman if
On 1/6/2010 12:05 PM, Brian Mathis wrote:
On Wed, Jan 6, 2010 at 12:34 PM, natecen...@linuxpowered.net wrote:
Alan McKay wrote:
I want to do a reboot of a couple of systems during our maintenance
window and fsck them, but would rather try it from home first and not
go to the data center.
At Wed, 06 Jan 2010 11:45:46 -0600 CentOS mailing list centos@centos.org
wrote:
On 1/6/2010 11:19 AM, Alan McKay wrote:
Hey folks,
I searched the list archives and found this :
echo AUTOFSCK_TIMEOUT=5 /etc/sysconfig/autofsck
echo AUTOFSCK_DEF_CHECK=yes /etc/sysconfig/autofsck
On Wed, Jan 06, 2010 at 12:30:15PM -0600, Les Mikesell wrote:
On 1/6/2010 12:05 PM, Brian Mathis wrote:
On Wed, Jan 6, 2010 at 12:34 PM, natecen...@linuxpowered.net wrote:
No out of band management?
My thoughts exactly. All servers should have this these days, be it
an integrated card
On Wed, Jan 6, 2010 at 1:05 PM, Brian Mathis brian.mat...@gmail.com wrote:
No out of band management?
My thoughts exactly. All servers should have this these days, be it
an integrated card or an IP-based KVM.
Oh believe me, I want to get there. It's high on my list this year
... I'm still
On 1/6/2010 2:36 PM, Alan McKay wrote:
On Wed, Jan 6, 2010 at 1:05 PM, Brian Mathisbrian.mat...@gmail.com wrote:
No out of band management?
My thoughts exactly. All servers should have this these days, be it
an integrated card or an IP-based KVM.
Oh believe me, I want to get there. It's
2010/1/6 Les Mikesell lesmikes...@gmail.com:
But, on the other hand they should never need it, except perhaps when
installing the OS if you don't use a full-auto method or clone disks.
Reminds me of the quote, In theory there is no difference between
theory and practice. In practise, there is.
On 1/6/2010 1:17 PM, Stephen Harris wrote:
On Wed, Jan 6, 2010 at 12:34 PM, natecen...@linuxpowered.net wrote:
No out of band management?
My thoughts exactly. All servers should have this these days, be it
an integrated card or an IP-based KVM.
But, on the other hand they should never
On Wed, Jan 06, 2010 at 02:11:10PM -0600, Les Mikesell wrote:
On 1/6/2010 1:17 PM, Stephen Harris wrote:
All hardware sucks, all software sucks.
Your machine _will_ go wrong and you _will_ need remote console access and
remote power ability. Especially if you have thousands of these
On Wed, Jan 6, 2010 at 3:11 PM, Les Mikesell lesmikes...@gmail.com wrote:
On 1/6/2010 1:17 PM, Stephen Harris wrote:
On Wed, Jan 6, 2010 at 12:34 PM, natecen...@linuxpowered.net wrote:
No out of band management?
My thoughts exactly. All servers should have this these days, be it
an
30 matches
Mail list logo
