All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Jan Kara <jack@suse.cz>
Cc: Akira Fujita <a-fujita@rs.jp.nec.com>,
	akpm@linux-foundation.org, adilger@dilger.ca,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: BUG? ext3: Allocate blocks over quota limit with mmap
Date: Mon, 02 Aug 2010 17:00:25 +0400	[thread overview]
Message-ID: <87lj8pb252.fsf@dmon-lap.sw.ru> (raw)
In-Reply-To: <20100802124359.GB3278@quack.suse.cz> (Jan Kara's message of "Mon, 2 Aug 2010 14:43:59 +0200")

Jan Kara <jack@suse.cz> writes:

> On Mon 02-08-10 09:22:12, Dmitry Monakhov wrote:
>> Akira Fujita <a-fujita@rs.jp.nec.com> writes:
>> 
>> > Hi ext3 maintainers,
>> >
>> > Could you look into this?
>> > If this is not a problem, it is good though.
>> Actually this is a problem. Because this issue makes quota just a fake
>> limit. I've done this test for ext4 and was satisfied with result,
>> but was too lazy to perform it on ext3/2 :(
>> At least we have to have testcase for that in xfstest-qa.
>> It seems that private page_mkwrite will be sufficient.
>> I'm working on that.
>   Yes, it's a long standing bug. Another manifestation of the bug is that
> we just throw away user's data without warning if we really cannot find
> space for it. Fixing it isn't completely trivial - doing block allocation
> during page_mkwrite really sucks performance-wise (tried that) so we
> basically have to implement delayed allocation for ext3 (and other
> filesystems) for mmaped writes and do reservation on page_mkwrite time and
> allocation on writepage time. I already have patches doing that but they
> depended on the truncate rewrite patch series and that was dragging on and
> on for half an year or so. Now I guess it's right time to rebase them and
> start pushing them again...
Indeed. Let implement it similar to ext4 "do not reserve quota space for
metadata but only for data". And speculatively charge metadata during
allocation. This makes page_mkwrite() simple and clean.
>
> 								Honza

  reply	other threads:[~2010-08-02 13:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29  2:08 BUG? ext3: Allocate blocks over quota limit with mmap Akira Fujita
2010-08-02  5:10 ` Akira Fujita
2010-08-02  5:22   ` Dmitry Monakhov
2010-08-02  5:57     ` Akira Fujita
2010-08-02 12:43     ` Jan Kara
2010-08-02 13:00       ` Dmitry Monakhov [this message]
2010-08-02 12:46   ` Jan Kara

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=87lj8pb252.fsf@dmon-lap.sw.ru \
    --to=dmonakhov@openvz.org \
    --cc=a-fujita@rs.jp.nec.com \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    /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.