On 06/26/2013 09:39 PM, kenji kondo wrote: > Hello Brian, > > Thank you very much for your advices. > Unfortunately, my gluster version 3.2.7 doesn't support the option. > But I'm planning to update the version in near future. > So is there recommended version although I planed 3.3.2? > >From looking at the source tree, this feature went into 3.3.1 so you should be fine with 3.3.2. Brian > Best regard, > Kondo > > 2013/06/27 1:39?Brian Foster <bfoster at redhat.com> ??????: > >> On 06/26/2013 10:55 AM, kenji kondo wrote: >>> Hello everyone, >>> >>> I'm using a stripe volume with 9 bricks. I have a question about file size >>> in bricks. >>> After copy a file of 700GB into the stripe volume, I checked the file size >>> by using "du" and/or "ls -ls" command. >>> But file size increase up to about 5TB. Also I checked the file size in >>> brick. Those file sizes was about 5TB / 9 brick for each brick. >>> In my understanding, the sparse file are created by glusterfsd with XFS >>> file system. So I expected that the actual file size shall be 700 GB / 9 >>> because file in brick has any holes according to 'stripe-block-size'. But >>> it seems not correct. >>> >>> This fact is not happy for me because actual available total size decrease. >>> But I feel something wrong for this fact. >>> Is this stripe volume normally working? Or I mistook something about >>> setting? >> >> It's most likely aggressive speculative preallocation in XFS that is >> filling up the space that is expected to remain unallocated. Independent >> workarounds have been made in recent versions of gluster and XFS to >> better deal with this issue. You can try to enable the >> cluster.stripe-coalesce option on your gluster volume to avoid this problem. >> >> Brian >> >>> Best regards, >>> K. Kondo >>> >>> >>> >>> _______________________________________________ >>> Gluster-users mailing list >>> Gluster-users at gluster.org >>> http://supercolony.gluster.org/mailman/listinfo/gluster-users >>
