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 <[email protected]> >>>> 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 >>>>> [email protected] >>>>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel >>>>> >>>> _______________________________________________ >>>> Ocfs2-devel mailing list >>>> [email protected] >>>> https://oss.oracle.com/mailman/listinfo/ocfs2-devel >>> >> >> >> _______________________________________________ >> Ocfs2-devel mailing list >> [email protected] >> https://oss.oracle.com/mailman/listinfo/ocfs2-devel > > > _______________________________________________ > Ocfs2-devel mailing list > [email protected] > https://oss.oracle.com/mailman/listinfo/ocfs2-devel > > _______________________________________________ Ocfs2-devel mailing list [email protected] https://oss.oracle.com/mailman/listinfo/ocfs2-devel
