5 ms·

That 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a0146830

by cheald 11y ago

That 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a014683018ac81c30df0b0823bf03272 https://github.com/mongodb/mongo/commit/b3322b86a014683018ac... There's plenty in Mongo to complain about, but grousing about the 32-bit limitation just makes you look like you're bad at reading introductory documentation.

joepie91_ 11y ago
This doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongodb.org/downloads https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of initscripts and such). It should have been in all the relevant places in the documentation, instead.
- cheald 11y ago
  Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that. It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility.
  - joepie91_ 11y ago
    > It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time. All the wrong places, as already stated. These are not the places where developers actually look. I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072 https://twitter.com/joepie91/status/622920351731843072 > [...] in the blog posts [...] Certainly not there. Go look around for MongoDB tutorials from the timespan where unacknowledged writes were the default, and almost none of them remark on the 32-bits limitation. > If you missed it, it's probably because you weren't paying attention. Nonsense. It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). > Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility. If pointing out extremely dangerous past negligence from the MongoDB developers "degrades my credibility" in your view, then you have some very strange ways to determine credibility.
    - cheald 11y ago
      > All the wrong places, as already stated. These are not the places where developers actually look. If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry. > Certainly not [in blog posts] http://blog.mongodb.org/post/137788967/32-bit-limitations http://blog.mongodb.org/post/137788967/32-bit-limitations > It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). I first started using Mongo in 2010 according to my gitlogs (after it having been on my radar for some time before that), and I very distinctly remember reading about the 32-bit limitation well before I'd ever installed it, because we were also using Varnish at the time, which has similar issues on 32-bit systems because it too uses (or at least, at that time used) memory-mapped files. The claim that the limitation was not documented well, or was hidden, or was generally unknown at that time is just simply false.
      - facetube 11y ago
        The word 'loss' does not appear on that page. There's a world of difference IMO between a rejected operation (which is what I would assume from that description – that the address space exhaustion would be detected and the database would stop accepting writes) and irreversible data loss.
        cheald 11y ago
        That's a consequence of their unacknowledged writes default - any write which failed for any reason wouldn't result in a rejection as far as the client is concerned (because the default was to shove the write request into the pipe and then continue without waiting for acknowledgement). As I mentioned earlier, most everyone acknowledges (heh) that as a bad default. If you were checking getLastError on your writes, you would see the write fail when you ran out of address space.
        facetube 11y ago
  - rdtsc 11y ago
    > Unacknowleged writes were a bad default. Bad defaults? It was defended as "this is ok because system is distributed" and there was a joke about it helping ace all the silly benchmarks. So it wasn't "oops we forgot to uncomment out the fsync line in the code". It was a deliberate decision. It was deceptive, and that is why many people hate MongoDB and wouldn't let it get even close to their data -- because have a track record of lying about the capabilities of their system.
  - threeseed 11y ago
    Also don't forget that almost every driver ignored the defaults and used acknowledged writes anyway.

by cheald 11y ago

joepie91_ 11y ago

This doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongodb.org/downloads https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of initscripts and such). It should have been in all the relevant places in the documentation, instead.

cheald 11y ago
Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that. It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility.
- joepie91_ 11y ago
  > It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time. All the wrong places, as already stated. These are not the places where developers actually look. I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072 https://twitter.com/joepie91/status/622920351731843072 > [...] in the blog posts [...] Certainly not there. Go look around for MongoDB tutorials from the timespan where unacknowledged writes were the default, and almost none of them remark on the 32-bits limitation. > If you missed it, it's probably because you weren't paying attention. Nonsense. It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). > Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility. If pointing out extremely dangerous past negligence from the MongoDB developers "degrades my credibility" in your view, then you have some very strange ways to determine credibility.
  - cheald 11y ago
    > All the wrong places, as already stated. These are not the places where developers actually look. If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry. > Certainly not [in blog posts] http://blog.mongodb.org/post/137788967/32-bit-limitations http://blog.mongodb.org/post/137788967/32-bit-limitations > It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). I first started using Mongo in 2010 according to my gitlogs (after it having been on my radar for some time before that), and I very distinctly remember reading about the 32-bit limitation well before I'd ever installed it, because we were also using Varnish at the time, which has similar issues on 32-bit systems because it too uses (or at least, at that time used) memory-mapped files. The claim that the limitation was not documented well, or was hidden, or was generally unknown at that time is just simply false.
    - facetube 11y ago
      The word 'loss' does not appear on that page. There's a world of difference IMO between a rejected operation (which is what I would assume from that description – that the address space exhaustion would be detected and the database would stop accepting writes) and irreversible data loss.
      - cheald 11y ago
        That's a consequence of their unacknowledged writes default - any write which failed for any reason wouldn't result in a rejection as far as the client is concerned (because the default was to shove the write request into the pipe and then continue without waiting for acknowledgement). As I mentioned earlier, most everyone acknowledges (heh) that as a bad default. If you were checking getLastError on your writes, you would see the write fail when you ran out of address space.
        facetube 11y ago
- rdtsc 11y ago
  > Unacknowleged writes were a bad default. Bad defaults? It was defended as "this is ok because system is distributed" and there was a joke about it helping ace all the silly benchmarks. So it wasn't "oops we forgot to uncomment out the fsync line in the code". It was a deliberate decision. It was deceptive, and that is why many people hate MongoDB and wouldn't let it get even close to their data -- because have a track record of lying about the capabilities of their system.
- threeseed 11y ago
  Also don't forget that almost every driver ignored the defaults and used acknowledged writes anyway.