4 ms·

The fact that it was "unstable" branch doesn't justify data loss or corruption. It can be used as an excuse to explain why server crashed, but not why data was

The fact that it was "unstable" branch doesn't justify data loss or corruption. It can be used as an excuse to explain why server crashed, but not why data was lost. This is big no-no in my book. Also, if the 500k documents limit on 32-bit architectures is true then it's just sad.

runT1ME 16y ago
so one class of bugs is OK, but another is not? scratches head. Have you ever done software development?
- piotrSikora 16y ago
  I never said that bugs are "OK", but yeah... Some bugs are acceptable and some are not. Data loss is never acceptable, especially not with databases. And yes, I did my share of software development...
  - cheald 16y ago
    Except in this case, it's not a bug, it's a design limitation. The MongoDB folks make no bones about it - the software is very limited on 32-bit systems. It warns you about it. It tells you to use 64-bit servers. If you insist on using the tool beyond the bounds for which it was designed to be used, that's your problem, as the developer. Is it a "bug" if you redline your car's engine and cause it to throw a rod? Or is that simply you pushing the machine past its design limits, despite the warnings not to do so?
    - piotrSikora 16y ago
      Data loss / corruption is design limitation?
      - cheald 16y ago
        Yes. MongoDB doesn't ensure a write to disk before returning on an insert operation (it is what is called "eventually consistent") in order to maintain high write throughput. Because it uses memory-mapped files, it can't address anything larger than a 32-bit pointer on a 32-bit system, and so you would execute an insert, and when the DB eventually tries to write it to disk, it would fail due to lack of resources. Because the write is asynchronous, the client doesn't realize that the data has not been serialized to disk, and you end up with effective data loss. Fixing this would require either a) not using memory-mapped files, or b) ensuring full durability on writes, both of which would massively slow down the data store as a whole.
- jm4 16y ago
  Bugs can be of varying severity. In some environments a crash bug (especially when using a dev branch) is tolerable and can be recovered from quickly and easily. In some systems this is par for the course and there are processes whose job it is to restart crashed processes all day long. I can't think of too many places where a data loss bug in an application whose sole purpose is to store and provide access to data would be even remotely acceptable.

runT1ME 16y ago

so one class of bugs is OK, but another is not? scratches head. Have you ever done software development?

piotrSikora 16y ago
I never said that bugs are "OK", but yeah... Some bugs are acceptable and some are not. Data loss is never acceptable, especially not with databases. And yes, I did my share of software development...
- cheald 16y ago
  Except in this case, it's not a bug, it's a design limitation. The MongoDB folks make no bones about it - the software is very limited on 32-bit systems. It warns you about it. It tells you to use 64-bit servers. If you insist on using the tool beyond the bounds for which it was designed to be used, that's your problem, as the developer. Is it a "bug" if you redline your car's engine and cause it to throw a rod? Or is that simply you pushing the machine past its design limits, despite the warnings not to do so?
  - piotrSikora 16y ago
    Data loss / corruption is design limitation?
    - cheald 16y ago
      Yes. MongoDB doesn't ensure a write to disk before returning on an insert operation (it is what is called "eventually consistent") in order to maintain high write throughput. Because it uses memory-mapped files, it can't address anything larger than a 32-bit pointer on a 32-bit system, and so you would execute an insert, and when the DB eventually tries to write it to disk, it would fail due to lack of resources. Because the write is asynchronous, the client doesn't realize that the data has not been serialized to disk, and you end up with effective data loss. Fixing this would require either a) not using memory-mapped files, or b) ensuring full durability on writes, both of which would massively slow down the data store as a whole.
jm4 16y ago
Bugs can be of varying severity. In some environments a crash bug (especially when using a dev branch) is tolerable and can be recovered from quickly and easily. In some systems this is par for the course and there are processes whose job it is to restart crashed processes all day long. I can't think of too many places where a data loss bug in an application whose sole purpose is to store and provide access to data would be even remotely acceptable.