Answer the question
In order to leave comments, you need to log in
MogoDB 2.2, Bad magic number in super-block?
2 times, on different hardware, linux kernel 2.6.not remembering and 3.5.7, ext3 and ext4 file system
The same situation:
1. There is a little less disk space than necessary for the growth of prealloc files.
2. Large write operation in Mongo
3. As a result, the complete destruction of the partition, Bad magic number in super-block, half of the files on the partition with Mongo turn out to be broken. Super-blocks cannot be restored by backup... The partition is mounted, but the files are irretrievably overwritten by other contents.
Then he tormented me this way and that, but he could not artificially achieve this. The first time this happened, I was very surprised, but wrote it off as “magnetic storms” and “a glitch in the OS kernel”. Although for 14 years of working with nix's I have not seen this ... There were no special suspicions on Mongu ... Although doubts crept in, since Mongu had only just installed it on a server, and before that it (server) worked for 1.5 years without any problems .
A search on the internet turned up several forum threads where people complain about "Bad magic number in super-block" and casually say that he had Mongo there. Usually they answer this in unison - "It looks like some kind of hardware failure or OS glitch." I would also answer the same way, if not for the same situation twice in a row on completely different machines, with different cores.
The only thing that unites these two situations is a large write operation in MongoDB.
Now nothing smarter than isolating (which I did) Mongo into separate partitions does not come to mind, since it was not possible to artificially repeat the situation ...
Maybe someone has come across and knows the exact conditions for repeating the experiment?
Answer the question
In order to leave comments, you need to log in
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question