02.09.2014, 07:18, "Joe Julian" <joe@xxxxxxxxxxxxxxxx>: > My first suggestion, that's not phrased the very carefully chosen words I usually use in order to be sure to be read as "nice", would be to stop screwing the system design by randomly doing things to the bricks that you clearly don't understand and instead let the software do what it was designed to do. mostly i followed gluster documentation and your blog ;), be assured that i'm not into doing "random" things, for now that was glusters part, but it wasn't designed as PRNG right ? > I phrase it harshly because you started your email with hostility, blaming developers that demonstrate more talent before breakfast than you enumerate in your description below over, apparently, you're three year long experience (based on the version history). ever thought about that one has to test EVERY CASE before delpoying it at customer sites ? > Most of the problems you describe can be caused directly by your "fixes" and cannot be caused by resizing xfs. > Mismatching layouts comes from having two fully populated servers with no xattrs as you describe creating later. The mentioned volume was freshly created and completely intact until i resized it (yep , inode numbers don't change ) it was fully populated by a fuse mount.. >> server1 was up and happy when you mount from it, but server2 spew input/output errors on several directories (for now just in that volume), > Illogical as there should be no difference in operation regardless of which server provides the client configuration. Did you somehow get the vols tree out of sync between servers? (if you mount it via fuse on server2 some dirs fail , fuse on server 1 will provide the full data, i also checked with "volume heal" and md5sum that they are in sync) the funny thing is that it seems also to be a hosntame resolution ( e.g. their OS system names are different than "glustN.somedomain.com" , but they try to connect via hostnames when utilising fuse mounts, so i put everything in /etc/hosts, i guess it was 2 late ) > I'm sure you can get a refund for the software. I just want it to work ! But yeah, for that amount of pain i would pay some personal trainer.. > Perhaps you're getting "tons" because you've already broken it. I don't great too much in my logs. >> really , even your worst *insertBigCorp* DB server will spit less logs, > Absolutely. In fact I think the bigger the Corp, the smaller and more obfuscated the logs. I guess that's a good thing? ^^for sure they want you to pay for SLA's , funding FOSS software nowadays is also "pay for support" to a certain extent > BTW... You never backed up your accusation that there is a "data black hole". remember when shd died ? glusterfs process also ate too much ram at random times. i just killed the volume everytime > > This can be solved. It's a complete mess though, by this account, and won't be easy. Your gfids and dht mappings may be mismatched, you may have directories and files with the same path on different bricks, and who knows what state your .glusterfs directory is in. ^^on the mentioned volume, as i told you, there is no .glusterfs anymore , they had to die (really i was in the mood for destruction , i didnt write "TRIGGER WARNING" in subject , sry for that), all xattrs were cleared out To make it clear: I just need some way to make it reliable and working, and if its necessary i give a f*** about syncing for 1 week, but in fact the data are the same on both sides i'll try a fresh installation of a third server, maybe i find differences in the confgs.. maybe see you on IRC _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
