Linux ocfs2 filesystem development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox