All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	Amir Goldstein <amir73il@gmail.com>, Theodore Tso <tytso@mit.edu>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext3: skip orphan cleanup on rocompat fs
Date: Mon, 28 Feb 2011 13:05:08 -0600	[thread overview]
Message-ID: <4D6BF1E4.6010503@redhat.com> (raw)
In-Reply-To: <20110228182201.GE20805@quack.suse.cz>

On 2/28/11 12:22 PM, Jan Kara wrote:
> On Mon 28-02-11 11:14:55, Rogier Wolff wrote:
>>
>> On Sat, Feb 26, 2011 at 10:40:19PM +0200, Amir Goldstein wrote:
>>> This patch skips the orphan cleanup if readonly compatible features
>>> would prevent the fs from being mounted (or remounted) readwrite.
>>
>> I use the "mount readonly" option to, for instance, view/check the
>> filesystem to determine wether or not I need to fsck first. I use the
>> "readonly" feature to prevent the mounting to be a mistake-prone
>> situation. It prevents e.g. applications from dropping temporary files
>> in my current directory.
>>
>> Every time fsck or such a cleanup does something, there is the option
>> of the cleanup or fixup being wrong. When you honour the "readonly"
>> request from the user, the careful user can go back to the situation
>> where he/she started.
>>
>> If the cleanup/fixup is really neccesary, do so in in-core buffers of
>   Mounting (even read-only) without recovering the journal will give you a
> view of a corrupted filesystem. Usually not what you want (although I agree
> with you that there are occasions where this *is* what you want).

Also, you can tell ext3/4 -not- to recover the journal, or, you can mark the
device RO before mount.  So while not the default behavior, it is at least
possible.

-Eric

  parent reply	other threads:[~2011-02-28 19:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-26 20:40 [PATCH] ext3: skip orphan cleanup on rocompat fs Amir Goldstein
2011-02-28 10:14 ` Rogier Wolff
2011-02-28 13:10   ` Amir Goldstein
2011-02-28 18:22   ` Jan Kara
2011-02-28 18:49     ` Ted Ts'o
2011-02-28 19:32       ` Jan Kara
2011-02-28 19:05     ` Eric Sandeen [this message]
2011-02-28 18:22   ` Ted Ts'o
2011-02-28 18:09 ` Jan Kara
2011-03-24 10:34   ` Amir Goldstein
2011-03-24 16:07     ` [stable] " Greg KH

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=4D6BF1E4.6010503@redhat.com \
    --to=sandeen@redhat.com \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.