From mboxrd@z Thu Jan 1 00:00:00 1970 From: Younger Liu Date: Fri, 2 Aug 2013 17:47:17 +0800 Subject: [Ocfs2-devel] Why ocfs2 haven't implemented "steal" for local_alloc system files? In-Reply-To: <51FAAF8C.9090006@oracle.com> References: <51F3A091.4090605@huawei.com> <20130801072008.GA15266@localhost> <51FA1E77.8060207@huawei.com> <51FAAF8C.9090006@oracle.com> Message-ID: <51FB8025.3030901@huawei.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ocfs2-devel@oss.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 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 > >