October 1, 201411 yr This story was so full of horror and nightmares... so ugly and frustrating... that I'll share it with you! From time to time I unrar fairly large (2-20 gigs) files from my Windows-7 Thinkpad into samba-shared cache dive on my unRAID server. And from time to time, the very first moment of creation of the to-be-unrared file in cache drive, caused Samba on unRAID to die and restart itself. Which takes a while. That would be no real biggie, but stupid WinRAR did not get it that the share is not available anymore, and kept unpacking into RAM, eating out the whole available memory... and worse, Windows task manager (even more stupid) did show that total memory is eaten, but did not show which application is eating it - it did not show the WinRAR RAM consumption grow! And I couldn't kill the glutton 'cause I did not know who he is. So when my laptops 4 gigs of RAM were exhausted, the stupid WIndows-7 soon stopped responding to mouse, to keyboard, to anything but the power button hold for many seconds... and after this dirty reboot I had to check the filesystem every time, and every time had to clean up the cache drive and start the whole unpacking again... After first gazillion of times going thru this pain, the stupid me finally realized that there is something wrong. After second gazillion of times I found that it was Samba murdered by WinRAR (remember, I did not know it from the beginning). After third gazillion of times I discovered that my first 17 data drives in unRAID server had Samba* export policy (public vs. secure, etc.) different from the rest 6 data drives... result of ill-considered unRAID expansion, probably. I made the Samba export policy uniform for all unRAID data drives... and... (knock-knock-knock on wood)... no Samba deaths since then. Moral: don't drink and expand your unRAID at the same time! _____________________ * -- No, I don't know why Samba even cares about the data drives, while only the cache drive is accessed.
Archived
This topic is now archived and is closed to further replies.