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: Fri, 2 Aug 2013 17:47:17 +0800 [thread overview]
Message-ID: <51FB8025.3030901@huawei.com> (raw)
In-Reply-To: <51FAAF8C.9090006@oracle.com>
On 2013/8/2 2:57, Srinivas Eeda wrote:
> On 08/01/2013 01:38 AM, Younger Liu wrote:
>> 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
> Is there a proof that localalloc=2048 performs better than default 256Mb
> ? local alloc currently looks for contiguous chunks. setting it to 2gb
> means it has to scan the whole bitmap to find that big of a chunk which
> in itself defeats the purpose of setting it to 2gb. I mean it might work
> well for a filesystem that just got formatted but as it gets used
> finding 2gb chunks is hard.
yes, I have proved that localalloc=2048 performs better, it improves about 5%.
In the scenario, ocfs2 volume stores virtual images which are very large,
for example, 20G or 50G.
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
prev parent reply other threads:[~2013-08-02 9:47 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
2013-08-01 16:49 ` Sunil Mushran
2013-08-01 18:57 ` Srinivas Eeda
2013-08-02 9:47 ` Younger Liu [this message]
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=51FB8025.3030901@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