From: tytso@mit.edu
To: Eric Sandeen <sandeen@redhat.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
Bill Nottingham <notting@redhat.com>
Subject: Re: [PATCH] default max mount count to unused
Date: Thu, 21 Jan 2010 20:29:29 -0500 [thread overview]
Message-ID: <20100122012929.GA21263@thunk.org> (raw)
In-Reply-To: <4B5785A5.2010505@redhat.com>
On Wed, Jan 20, 2010 at 04:37:25PM -0600, Eric Sandeen wrote:
> From: Bill Nottingham <notting@redhat.com>
>
> Anaconda has been setting the max mount count on the root fs
> to -1 (unused) for ages.
>
> I (Eric) tend to agree that using mount count as a proxy for potential
> for corruption seems odd. And waiting for fsck on a reboot just because
> it's number 20 (or so) is painful. Can we just turn it off by default?
>
> I wouldn't mind killing the periodic check as well, but consider
> this a trial balloon. :)
I think it would be better to make this be something tunable via
mke2fs.conf. And as a profile option, maybe we would want this to be
something where we periodically force a full fsck check and then send
TRIM commands down to the SSD. Given the size and speed of SSD's,
doing periodic TRIM's every N mounts mike actually be a good thing.
(It's dangerous to do a TRIM without doing a full fsck since if the
block allocation bitmap isn't quite right, the user could lose data.)
- Ted
next prev parent reply other threads:[~2010-01-22 1:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 22:37 [PATCH] default max mount count to unused Eric Sandeen
2010-01-22 0:22 ` Andreas Dilger
2010-01-22 1:37 ` tytso
2010-01-22 1:37 ` [linux-lvm] " tytso
2010-01-22 17:42 ` Eric Sandeen
2010-01-22 18:35 ` Andreas Dilger
2010-01-22 1:29 ` tytso [this message]
2010-01-22 3:37 ` Eric Sandeen
2010-01-22 8:09 ` Andreas Dilger
2010-01-22 17:02 ` Ric Wheeler
2010-01-22 18:40 ` Andreas Dilger
2010-01-22 18:57 ` Ric Wheeler
2010-01-22 19:06 ` Andreas Dilger
2010-01-22 19:59 ` Eric Sandeen
2010-01-22 20:58 ` Valerie Aurora
2010-01-22 23:18 ` tytso
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=20100122012929.GA21263@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=notting@redhat.com \
--cc=sandeen@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.