Re: Keep auto-periodic fsck's enabled on ext3 partitions?

2005-01-07 Thread Glenn Oppegard
Thanks for weighing in with your opinion, which was basically what I 
was planning to do anyways unless I heard otherwise. We don't run 
cutting-edge kernels, only upgrading for important bug or security 
patches. Combined with nightly backups of customer data, I think we'll 
be pretty safe disabling auto-fscks (knock on wood).

Thanks again,
Glenn Oppegard
Aktiom Networks LLC
http://www.aktiom.net
Linux Virtual Private Servers for Professionals
On Jan 6, 2005, at 4:48 AM, Wouter Verhelst wrote:
On Thu, Jan 06, 2005 at 01:26:02AM -0700, Glenn Oppegard wrote:
Hello,
We have production machines that have ext3 partitions bigger than
100GB. On our last kernel upgrade, we were surprised to see the
machines do an fsck on all partitions even though they were unmounted
cleanly.
Upon further investigation we found the tune2fs options that force
fscks of partitions after a certain number of mounts, or after a
certain period of time since the last fsck (6 months in our case). My
question is, is it detrimental to disable these auto-checks and not 
run
fsck periodically?
If you always upgrade to the latest kernel when it's out, it's probably
a good idea to leave it on; otherwise, and as long as you don't
experience problems, I suggest to switch it off.
The man page for tune2fs says it's not wise...
That is mostly relevant for systems that don't take regular backups. If
you do (and for the sake of your customers, I hope that is the case),
the extra precaution isn't really necessary, and probably a bad idea if
the cost involved (in terms of downtime) is too high.
The idea of the fsck is so that you would notice if anything out of the
ordinary is going on in the kernel. If you are, however, running the
same kernel all the time, either nothing will happen (and the fsck's 
are
superfluous), or your kernel is broken and you'll be fucked anyway (and
the fsck's won't help you).

--
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact 
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


Re: Keep auto-periodic fsck's enabled on ext3 partitions?

2005-01-06 Thread Russell Coker
On Thursday 06 January 2005 22:48, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> That is mostly relevant for systems that don't take regular backups. If
> you do (and for the sake of your customers, I hope that is the case),
> the extra precaution isn't really necessary, and probably a bad idea if
> the cost involved (in terms of downtime) is too high.

One thing that has been suggested is to use LVM and fsck a snapshot.  If fsck 
on a snapshot LV indicates that nothing other than journal replay is really 
needed then you can keep running.  If it finds some more serious problem then 
you can consider other options.

I don't know of anyone actually implementing this due to fsck not being 
painful enough.  It would be interesting to read some reports of someone 
actually doing this in the field.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Keep auto-periodic fsck's enabled on ext3 partitions?

2005-01-06 Thread Henrique de Moraes Holschuh
On Thu, 06 Jan 2005, Wouter Verhelst wrote:
> If you always upgrade to the latest kernel when it's out, it's probably
> a good idea to leave it on; otherwise, and as long as you don't
> experience problems, I suggest to switch it off.

Also, if you do not have ECC RAM (with a chipset/arch that does ECC
monitoring and auto-scrubbing, since Linux is completely retarded on that
area for ia32), you should fsck periodically.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Keep auto-periodic fsck's enabled on ext3 partitions?

2005-01-06 Thread Wouter Verhelst
On Thu, Jan 06, 2005 at 01:26:02AM -0700, Glenn Oppegard wrote:
> Hello,
> 
> We have production machines that have ext3 partitions bigger than 
> 100GB. On our last kernel upgrade, we were surprised to see the 
> machines do an fsck on all partitions even though they were unmounted 
> cleanly.
> 
> Upon further investigation we found the tune2fs options that force 
> fscks of partitions after a certain number of mounts, or after a 
> certain period of time since the last fsck (6 months in our case). My 
> question is, is it detrimental to disable these auto-checks and not run 
> fsck periodically?

If you always upgrade to the latest kernel when it's out, it's probably
a good idea to leave it on; otherwise, and as long as you don't
experience problems, I suggest to switch it off.

> The man page for tune2fs says it's not wise...

That is mostly relevant for systems that don't take regular backups. If
you do (and for the sake of your customers, I hope that is the case),
the extra precaution isn't really necessary, and probably a bad idea if
the cost involved (in terms of downtime) is too high.

The idea of the fsck is so that you would notice if anything out of the
ordinary is going on in the kernel. If you are, however, running the
same kernel all the time, either nothing will happen (and the fsck's are
superfluous), or your kernel is broken and you'll be fucked anyway (and
the fsck's won't help you).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]