FYI - Fastmail web client has Offline support in beta right now. https://www.fastmail.com/blog/offline-in-beta/
Omg it's 1970 and we have IMAP now... Oh wait...
Why we use our own hardware
481–490 of 547 posts
Re: Why we use our own hardware
#482The fact that Fastmail work like this, are transparent about what they're up to and how they're storing my email and the fact that they're making logical decisions and have been doing so for quite a long time is exactly the reason I practically trip over myself to pay them for my email. Big fan of Fastmail.
I recently officially became a Fastmail user when pobox.com transitioned to Fastmail, and was very impressed with customer service when I had a technical question.
Re: Why we use our own hardware
#483I don't trust anything from fastmail after they bought pobox and forced me onto their new service which fails at the one thing pobox did well--forwarding email. They also refused to give me a refund (prorated or not) for removing the product I was using and substituting a defective one.
What problems have you had? I also came over from pobox and thought that the transition was quite straightforward.
Re: Why we use our own hardware
#484I'm a little surprised it seems they didn't have some existing compression solution before moving to zfs. With so much repetitive text across emails I would think there would be a LOT to gain, such as from dictionaries, compressing many emails into bigger blobs, and fine-tuning compression options.
Keen to move certain tasks to ZFS but not the ones that matter...
Frankly given emails are normally ~4kB objects I suspect the compression overheads are probably not that worth it unless it's for attachments only. Not attacking ZFS it's compression and checksumming are among best in class, but the compression would work better if it weren't limited to small files. Here ZFS has made a lot of wins I've not had a problem with many files on ZFS due to L1/L2 ARC but the cost is metadata ops can be painful on many small files.
The evidence they IOPS limited it that they went for SSD or better when they could store the same capacity on rust for much cheaper now.
Yeah I think moving the compression or file access up to abstract what is being written to disk ala protonmail (I don't like their offerings, but like their tech) means you can have compression over 4MB not 4kB blocks which matters when you recall data from disks for , I don't know... Backups or search?
also remember RAID!=backups ;)
Re: Why we use our own hardware
#485zfs encryption is still corrupting datasets when using zfs send/receive for backup (huge win for mail datasets), would be cautious about using it in production: https://github.com/openzfs/zfs/issues/12014
Please stop using send/recv . Your backups should be based on non ZFS tech to avoid all your eggs in one basket.
Yes send/recv is fine for immediate recovery, but other than block level replication for immediate (my server is now inside the tornado) recovery this isn't advised.
Also, who cares if a single filesystem dies, that's why you have inter-server replication. Nuke the bad server and rebuild before the next 3 or 4 die.
Re: Why we use our own hardware
#486gmail does spam filtering very well for me. fastmail on the other hands, puts lots of legit emails into spam folder. manually marking "not spam" doesn't help other than that, i'm happy with fastmail.
>fastmail on the other hands, puts lots of legit emails into spam folder. manually marking "not spam" doesn't help
Fastmail explicitly says that moving mail to/from a spam folder via a mail client does not automaticallyl retrain. https://www.fastmail.help/hc/en-us/articles/1500000278142-Im...> (I never did figure out if Gmail acts the same way or not.)
Re: Why we use our own hardware
#487Earlier quoted context omitted.
That depends where it's hosted and how it's encrypted. Cloud hosts can just reach into your RAM, but dedicated server hosts would need to provision that before deploying the server, and colocation providers would need to take your server offline to install it.
Colocated / Dedicated is not Cloud, AFAICT. It's the "traditional hosting", not elastic / auto-scalable. You of course may put your own, highly tamper-proof boxes in a colocation rack, and be reasonably certain that any attempt to exfiltrate data from them won't be invisible to you. By doing so, you share nothing with your hosting provider, you only rent rack space / power / connectivity.
And this is why I colocate, because all the data that hits my server is my data.
Sure I do have an AUP/T&C but without proper warrant no one is allowed to touch my server.
Case is monitored if it's opened. Encrypted on start-up, USB disabled. I just wished I had my own /24.
Re: Why we use our own hardware
#488Earlier quoted context omitted.
Ceph is most certainly not the only game in town. It's good and stuff, but it's just tech. We're using protocol level replication for each of our data stores.
No, let's be honest. CEPH is the only solution for data management at this scale (sub to few PB). The solution which is independent of application or workload. The market share, fact IBM is moving people off other projects internally for this, and the massive backing shows this. Yes you can have all or a bunch of these features like failure domains via other routes/products but none have all of the stuff together in…
I mean, I'm happy to have this argument. CEPH is content agnostic and that's fantastic most of the time. Cyrus replication is data aware, so it's not just replicating the data, it's doing integrity checking and data model consistency handling.
Most of all, it's doing split brain recovery; which - if we wanted CP rather than AP then we wouldn't need, but that wasn't the original design.
If I was redoing this from scratch, I'd maybe do Ceph or similar and update Cyrus to work well with it, but that would be a big change from the current design.
Anyway, I'm happy to stipulate that Ceph is great tech, without going and telling other people that it's the only choice.
Re: Why we use our own hardware
#489Earlier quoted context omitted.
The other part is that when us-east-1 goes down, you can blame AWS, and a third of your customer's vendors will be doing the same. When you unplug the power to your colo rack while installing a new server, that's on you.
OTOH, when your company's web site is down you can do something about it. When the CEO asks about it, you can explain why its offline and more importantly what is being done to bring it back. The equivalent situation for those who took a cloud based approach is often... ¯\_(ツ)_/¯
When AWS goes down you can tell your boss that dozens of people are working to get it back up.
Re: Why we use our own hardware
#490Earlier quoted context omitted.
OTOH, when your company's web site is down you can do something about it. When the CEO asks about it, you can explain why its offline and more importantly what is being done to bring it back. The equivalent situation for those who took a cloud based approach is often... ¯\_(ツ)_/¯
The more relevant question is whether my efforts to do something lead to a better and faster result than my cloud providers efforts to do something. I get it - it feels powerless to do nothing, but for a lot of organizations I’ve seen the average downtime would still be higher.
I worked in IT for a state government and they had a partial outage of their Exchange server that lasted over 2 weeks. It triggered a full migration to Exchange online.