linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Bryn M. Reeves" <bmr@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Re: About fstab and fsck
Date: Fri, 13 Feb 2009 09:48:33 +0000	[thread overview]
Message-ID: <499541F1.3080501@redhat.com> (raw)
In-Reply-To: <jwvvdrf5pbn.fsf-monnier+gmane.linux.lvm.general@gnu.org>

Stefan Monnier wrote:
>>>>> filesystem... so considering its size, I'd turn it off.
>>>>> Hopefully the "fsck takes _forever_" problem will die when
>>>>> btrfs becomes the standard filesystem.
>>>> Just a reminder: Linux has xfs since 2002. A full-blown fsck
>>>> on xfs is a rare thing.
>>> Similarly, I don't know of any case where fsck on an ext3
>>> partition turned out to be useful.  As a matter of fact, my
>>> home router's ext3
>> I wouldn't go that far. It all depends what messed the file
>> system up in the first place.
> 
> That's the thing: nothing did.  So why run fsck at all?

I read your statement to mean running fsck on a broken file system
didn't do anything useful. If it's not broken, don't fix it. :)

>> Ext3 bugs, minor scribbling and suchlike generally get tidied up 
>> reasonably well by e2fsck.  It's quite true that with major
>> corruption to the file system there's often not an awful lot left
>> afterwards but that's true of many other file systems as well.
> 
> Oh, you're thinking of using fsck for recovery purposes. That's a
> different situation.  I was just talking about the idea of "not 
> needing to do fsck any more", which is pretty much already the case
> for XFS and ext3, AFAIK.

Ah, you mean the regular mount count / interval checks? Yes, theses
should be unnecessary with a journaled file system (this is why
anaconda has disabled those checks for file systems that it creates
for years).

The paranoid might still like to run these checks occasionally to
detect any latent corruption but I'd be much more inclined to do that
on my systems if we had an fsck that ran in a reasonable amount of
time for large volumes.

> Actually I call it "router" because it was sold as such and it
> replaced a machine which I originally used as such as well.  Really
> it's just a small home server which stores&plays my music, stores
> my movies and other such things, ...  It doesn't actually do any
> routing at all.

Ah, cool; I have a similar box (although it does do some routing) that
also has a fairly sizeable file system. Currently it's configured to
never fsck on boot for the reasons discussed here.

Regards,
Bryn.

  reply	other threads:[~2009-02-13  9:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 15:45 [linux-lvm] About fstab and fsck Madan Thapa
2009-02-11 21:58 ` David Robinson
2009-02-11 22:03   ` Chris Cox
2009-02-11 22:21     ` Madan Thapa
2009-02-11 22:25       ` Madan Thapa
2009-02-12  0:37     ` David Robinson
2009-02-12  8:38   ` Martin Schröder
2009-02-12 20:13     ` [linux-lvm] " Stefan Monnier
2009-02-12 20:17       ` Bryn M. Reeves
2009-02-12 21:20         ` Stefan Monnier
2009-02-13  9:48           ` Bryn M. Reeves [this message]
2009-02-13 20:34             ` f-lvm
2009-02-13 21:55               ` Martin Schröder
2009-06-11 10:00             ` [linux-lvm] SCSI error: return code = 0x00070000 - device-mapper: multipath Mark Reardon
2009-06-11 10:27               ` [linux-lvm] " Bryn M. Reeves
2009-02-13 19:41       ` [linux-lvm] Re: About fstab and fsck David Robinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499541F1.3080501@redhat.com \
    --to=bmr@redhat.com \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).