All of lore.kernel.org
 help / color / mirror / Atom feed
From: Younger Liu <younger.liu@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Why ocfs2 haven't implemented "steal" for local_alloc system files?
Date: Thu, 1 Aug 2013 16:38:15 +0800	[thread overview]
Message-ID: <51FA1E77.8060207@huawei.com> (raw)
In-Reply-To: <20130801072008.GA15266@localhost>

On 2013/8/1 15:20, Joel Becker wrote:
> Basically, there's so little in the cache that stealing would be too
> complex.  Really we just want to fall back to the global, and if that is
> empty, you're near enough ENOSPC that it doesn't much matter.
> 
> Joel
> 
Localalloc is a mount option. When mounting an ocfs2 volume, localalloc can
be set a larger size. For example, 2G or a larger number.

In a multi-nodes cluster, all nodes mount ocfs2 volume with localalloc=2048
for performance consideration, if a node claims space for a file, but there 
is no space in the local_alloc and global_bitmap. It would return ENOSPC.
However, other nodes may have lots of space which have been claimed 
in local_alloc, so ENOSPC cannot reflect the actual situation.

IMO, if there is no space both in the local_alloc and global_bitmap,
it should steal space from other nodes local_alloc.

Thx, 
Younger.

> On Wed, Jul 31, 2013 at 08:33:48PM -0700, Sunil Mushran wrote:
>> Because it makes no sense. Unlike inode/extent allocs, local_alloc is a
>> temporary cache. If you fail to allocate, you fallback to the global bitmap.
>>
>>
>> On Sat, Jul 27, 2013 at 3:27 AM, Younger Liu <younger.liu@huawei.com> wrote:
>>
>>> Hi,
>>>   While analyzing ocfs2 block allocation, I found:
>>>   When claiming space from inode_alloc (or extent_alloc) system files,
>>> if there is no enough space in inode_alloc (or extent_alloc) and
>>> global_bitmap, it could steal space from other slots.
>>>   But when claiming space from local_alloc system files, and no
>>> enough space in local_alloc and global_bitmap, it returns -ENOSPC.
>>>
>>>   Why ocfs2 haven't implemented "steal" for local_alloc system files?
>>>   Is there any some reasons?
>>>
>>>
>>> _______________________________________________
>>> Ocfs2-devel mailing list
>>> Ocfs2-devel at oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>>>
> 
>> _______________________________________________
>> Ocfs2-devel mailing list
>> Ocfs2-devel at oss.oracle.com
>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 
> 

  reply	other threads:[~2013-08-01  8:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-27 10:27 [Ocfs2-devel] Why ocfs2 haven't implemented "steal" for local_alloc system files? Younger Liu
2013-08-01  3:33 ` Sunil Mushran
2013-08-01  7:20   ` Joel Becker
2013-08-01  8:38     ` Younger Liu [this message]
2013-08-01 16:49       ` Sunil Mushran
2013-08-01 18:57       ` Srinivas Eeda
2013-08-02  9:47         ` Younger Liu

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=51FA1E77.8060207@huawei.com \
    --to=younger.liu@huawei.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.