<div dir="ltr">The complexity is not worth it. 2G*16 nodes is only 32G. That's rounding error in systems that use this file system. And you are assuming that all other nodes have all 2G in their cache. If a node runs out of space, a more realistic scenario is that most other nodes are also close to the end.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 1:38 AM, Younger Liu <span dir="ltr"><<a href="mailto:younger.liu@huawei.com" target="_blank">younger.liu@huawei.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013/8/1 15:20, Joel Becker wrote:<br>
> Basically, there's so little in the cache that stealing would be too<br>
> complex. Really we just want to fall back to the global, and if that is<br>
> empty, you're near enough ENOSPC that it doesn't much matter.<br>
><br>
> Joel<br>
><br>
</div>Localalloc is a mount option. When mounting an ocfs2 volume, localalloc can<br>
be set a larger size. For example, 2G or a larger number.<br>
<br>
In a multi-nodes cluster, all nodes mount ocfs2 volume with localalloc=2048<br>
for performance consideration, if a node claims space for a file, but there<br>
is no space in the local_alloc and global_bitmap. It would return ENOSPC.<br>
However, other nodes may have lots of space which have been claimed<br>
in local_alloc, so ENOSPC cannot reflect the actual situation.<br>
<br>
IMO, if there is no space both in the local_alloc and global_bitmap,<br>
it should steal space from other nodes local_alloc.<br>
<br>
Thx,<br>
Younger.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Wed, Jul 31, 2013 at 08:33:48PM -0700, Sunil Mushran wrote:<br>
>> Because it makes no sense. Unlike inode/extent allocs, local_alloc is a<br>
>> temporary cache. If you fail to allocate, you fallback to the global bitmap.<br>
>><br>
>><br>
>> On Sat, Jul 27, 2013 at 3:27 AM, Younger Liu <<a href="mailto:younger.liu@huawei.com">younger.liu@huawei.com</a>> wrote:<br>
>><br>
>>> Hi,<br>
>>> While analyzing ocfs2 block allocation, I found:<br>
>>> When claiming space from inode_alloc (or extent_alloc) system files,<br>
>>> if there is no enough space in inode_alloc (or extent_alloc) and<br>
>>> global_bitmap, it could steal space from other slots.<br>
>>> But when claiming space from local_alloc system files, and no<br>
>>> enough space in local_alloc and global_bitmap, it returns -ENOSPC.<br>
>>><br>
>>> Why ocfs2 haven't implemented "steal" for local_alloc system files?<br>
>>> Is there any some reasons?<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Ocfs2-devel mailing list<br>
>>> <a href="mailto:Ocfs2-devel@oss.oracle.com">Ocfs2-devel@oss.oracle.com</a><br>
>>> <a href="https://oss.oracle.com/mailman/listinfo/ocfs2-devel" target="_blank">https://oss.oracle.com/mailman/listinfo/ocfs2-devel</a><br>
>>><br>
><br>
>> _______________________________________________<br>
>> Ocfs2-devel mailing list<br>
>> <a href="mailto:Ocfs2-devel@oss.oracle.com">Ocfs2-devel@oss.oracle.com</a><br>
>> <a href="https://oss.oracle.com/mailman/listinfo/ocfs2-devel" target="_blank">https://oss.oracle.com/mailman/listinfo/ocfs2-devel</a><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>