From: Tao Ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/2] ocfs2: flush truncate log in case it contains too many clusters.
Date: Tue, 12 Oct 2010 12:55:35 +0800 [thread overview]
Message-ID: <4CB3EA47.90003@oracle.com> (raw)
In-Reply-To: <20101012002345.GL8031@wotan.suse.de>
Hi Mark,
On 10/12/2010 08:23 AM, Mark Fasheh wrote:
> Hi Tao,
>
> On Sun, Sep 19, 2010 at 03:20:28PM +0800, Tao Ma wrote:
>> When we test whether we need to flush truncate log in
>> ocfs2_truncate_log_needs_flush, we only take care of
>> whether the truncate log is full. But if the volume is
>> small and we have large block size(in this case truncate
>> log can store too many records), we may be too late
>> for flushing if the user create/write/delete files quickly.
>>
>> So I add a new FLUSH_TRUNCATE_LOG_RATIO so that we will also
>> check whether the number of truncated clusters has reached
>> a watermark, if yes, flush the truncate log.
>> It resolves the ossbug #1288 somehow.
>
> The problem with the ratio of course is that it doesn't necessarily
> correlate to when we actually run out of space. Also, I am concerned that a
> 10% disk-size limit on truncate log could hurt us in some cases (maybe
> truncate of a huge file in the middle of some other rms?)
>
>
> How about an alternate solution - at the time we see -ENOSPC (during write
> for example), why not drop all the allocator locks (global bitmap, local
> alloc) and then look at the truncate log for a sufficiently sized extent?
> Removing it from the truncate log at that point shouldn't be too hard and
> we'd always be able to fill it up completely.
Thanks for the review. Your suggestion does make sense, but I am afraid
it will surely be more complicated than this patch.
Anyway, I will be on a trip until next week and I will work on it when I
come back.
Regards,
Tao
next prev parent reply other threads:[~2010-10-12 4:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-19 7:19 [Ocfs2-devel] [PATCH 0/2 V2] ocfs2: Resolve the problem of truncate log flush Tao Ma
2010-09-19 7:20 ` [Ocfs2-devel] [PATCH 1/2] ocfs2: flush truncate log in case it contains too many clusters Tao Ma
2010-10-12 0:23 ` Mark Fasheh
2010-10-12 4:55 ` Tao Ma [this message]
2010-09-19 7:20 ` [Ocfs2-devel] [PATCH 2/2] ocfs2: Start journal checkpoint if we have too many truncated clusters Tao Ma
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=4CB3EA47.90003@oracle.com \
--to=tao.ma@oracle.com \
--cc=ocfs2-devel@oss.oracle.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.