<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<pre> </pre>
<blockquote>Hello, some time has gone since i reported that problem. I watch this and find out, that if i run rebalance, which sorts the free space on all 3 bricks to the same, i can copy new files on the volume. Now i have again this situation on free disk space b1: 180GB, b2: 178GB, b3:41GB. If i now copy one file with 46GB size, gluster will copy that to b3 which doesnt have anough free space. Ok i run rebalance which needs many hours, can i speed up this? and can i while it is running copy files to the volume?, and after that i have b1:130, b2:133 and b3:133GB. Ok copy the file again and it fills up b2. After that copy further more files and have the same situation for now b2. My question now - is this an normal behaviour of an distributed glustervolume and must i run the rebalance on my own, where is the problem? Need serious help.thx</blockquote>
<div>Why not configure striping (with *huge* stripe size) and min-free-disk at the same time. set cluster.min-free-disk to a few GB, preferably larger than your expected maximum single file size. set cluster.stripe-block-size to a few GB, again preferably larger than your expected maximum single file size. Now, *usually* you will get the whole file in one "stripe" block on the one expected volume, *unless* that volume already is low on space, due to "min-free-disk". And, even if you should write tons of data, you will be able to store single files larger even than your largest volume, because of the "striping". But if you really fill it up to the last few percent, then, yes, it will still correctly tell you "ENOSPC". <span class="sig">-- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting <a href="http://www.linbit.com" target="_blank">http://www.linbit.com</a> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.</span></div>
<div> </div>
<div>---------------</div>
<div> </div>
<div>Hi Lars,</div>
<div> </div>
<div>i am not sure if we talk about the same system, but i use an only distributed system not a distributed striped one. I expected max single filesize at 50GB, but this is cout not offen be the case. But for understanding:</div>
<div>cluster.min-free-disk = size of space which should kept free on disk of each brick for the volume. prevent disk from running full, right? So i would set it to 50GB?</div>
<div>cluster.stripe-block-size = the size in bytes of an file that is written or read on the volume (default 128kb). smaller = better for small files, bigger better for big files? So i would set it to 50GB??? As i found in the docu i could set it for special filetypes, right? so i could set it special for .iso and .img Images???</div>
<div> </div>
<div>Situation Brick1 = 90GB, Brick2 = 30GB, Brick3=41GB. File to copy has 48GB. File would not copied to Brick2 and Brick3 but to Brick1 due to values above? Sounds logical, but a) should this not be an automatism in glusterfs? and b) i am not sure if the stripe-block-size works like this. i understand it as the maximum size which is read and written for a stripe. e.g. if the file has 256kb it reads first 128kb and than the other 128kb, but if i set it to 256kb it would read the full size of this file, right?</div>
<div> </div>
<div>thx for helping</div>
</div></div></body></html>