From: Amir Goldstein <amir73il@gmail.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/2] ext4: handle errors in ext4_clear_blocks()
Date: Mon, 21 Mar 2011 06:23:36 +0200 [thread overview]
Message-ID: <AANLkTi=3bdCC5=EPPUC_DNsq9pHMtJ2CSciTrRwZ4fcH@mail.gmail.com> (raw)
In-Reply-To: <20110321013749.GE4135@thunk.org>
On Mon, Mar 21, 2011 at 3:37 AM, Ted Ts'o <tytso@mit.edu> wrote:
> On Tue, Mar 01, 2011 at 02:28:26PM +0200, Amir Goldstein wrote:
>> +out_err:
>> + ext4_std_error(inode->i_sb, err);
>> + return err;
>
> Umm, you do realize this function will mark the file system as dirty,
> and possibly remount the file system read-only, or panic the system,
> right?
I am counting on that. In fact I think we should not allow snapshots
and errors=continue,
otherwise we just as good (bad) as LVM snapshot that vanishes when it
runs out of space.
>
> That's appropriate for normal journal failures (since there's no
> recovering from them), but if you're proposing that a simple lack of
> free blocks when doing a COW operation will result in a ENOSPC, all a
> malicious userspace application needs to do to potentially bring the
> system down is to attempt to unlink or truncate a file while COW
> snapshots are enabled.....
It's not that easy to cause ENOSPC during COW.
s_snapshot_r_blocks has blocks reserved for COW,
but I do want the fs to freeze if that reservation somehow runs out.
The reservation is based on metadata size estimation, calculated
for no of used inodes no of dirs and no of used blocks. It may fall
short when there are very many hard links or very long file names,
resulting in lots of directory blocks and when all of them are COWed.
short in many hard links
>
> Do you really want me to include this patch? I think you may want to
> rethink how you want to handle this case....
I do, because when errors=remount-ro, this function emmits lots of
"journal has aborted" errors, which are of no useful to anyone...
>
> - Ted
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-03-21 4:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-01 12:28 [PATCH 2/2] ext4: handle errors in ext4_clear_blocks() Amir Goldstein
2011-03-21 1:32 ` Ted Ts'o
2011-03-21 1:37 ` Ted Ts'o
2011-03-21 4:23 ` Amir Goldstein [this message]
2011-03-21 5:18 ` Amir Goldstein
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='AANLkTi=3bdCC5=EPPUC_DNsq9pHMtJ2CSciTrRwZ4fcH@mail.gmail.com' \
--to=amir73il@gmail.com \
--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 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).