No, I am speaking about stranges in write to existing files. Maybe 'broken', but maybe root of trouble in my options (flush-behind or some else)? Illtustration of my situation: root at virtual:~# rm testfile.bin # removing old file root at virtual:~# dd if=/dev/zero of=testfile.bin bs=100M count=3 # testing speed on new file 3+0 records in 3+0 records out 314572800 bytes (315 MB) copied, 0.268943 s, 1.2 GB/s root at virtual:~# dd if=/dev/zero of=testfile.bin bs=100M count=3 # testing speed on existing file. WOW! 3+0 records in 3+0 records out 314572800 bytes (315 MB) copied, 290.361 s, 1.1 MB/s Why writing to existing file is soooooooooooooooo slooooooooooooow? 2013/3/1 Brian Candler <B.Candler at pobox.com> > On Fri, Mar 01, 2013 at 03:30:07PM +0600, Nikita A Kardashin wrote: > > If I try to execute above command inside virtual machine (KVM), first > > time all going right - about 900MB/s (cache effect, I think), but if I > > run this test again on existing file - task (dd) hungs up and can be > > stopped only by Ctrl+C. > > Overall virtual system latency is poor too. For example, apt-get > > upgrade upgrading system very, very slow, freezing on "Unpacking > > replacement" and other io-related steps. > > Does glusterfs have any tuning options, that can help me? > > If you are finding that processes hang or freeze indefinitely, this is not > a question of "tuning", this is simply "broken". > > Anyway, you're asking the wrong person - I'm currently in the process of > stripping out glusterfs, although I remain interested in the project. > > I did find that KVM performed very poorly, but KVM was not my main > application and that's not why I'm abandoning it. I'm stripping out > glusterfs primarily because it's not supportable in my environment, because > there is no documentation on how to analyse and recover from failure > scenarios which can and do happen. This point in more detail: > http://www.gluster.org/pipermail/gluster-users/2013-January/035118.html > > The other downside of gluster was its lack of flexibility, in particular > the > fact that there is no usage scaling factor on bricks, so that even with a > simple distributed setup all your bricks have to be the same size. Also, > the object store feature which I wanted to use, has clearly had hardly any > testing (even the RPM packages don't install properly). > > I *really* wanted to deploy gluster, because in principle I like the idea > of > a virtual distribution/replication system which sits on top of existing > local filesystems. But for storage, I need something where operational > supportability is at the top of the pile. > > Regards, > > Brian. > -- With best regards, differentlocal (www.differentlocal.ru | differentlocal at gmail.com), System administrator. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130301/47e64f68/attachment.html>
