Wandering Thoughts archives


The other reason certified email won't solve the spam problem

The other problem with certified email as a way to solve the spam problem is a basic idea:

People don't pay for what they don't need.

So ask yourself: who actually needs to pay for a certification that their email isn't spam?

Significant sources of good email certainly don't need to pay; people already want email from them and will raise heck if stuff starts getting blocked. No one can afford to block GMail, for example.

There's some motivation for smaller sources of good email to pay up, but this only works if big ISPs and email providers do anything with the certification, which is unlikely. And even if it works, the smaller sources are going to feel that they're being held to ransom, since they have to pay for something that the big sources don't.

There's a big motivation for senders of unsolicited email to pay up, since people they're sending it to don't know to complain to their ISPs if it doesn't arrive. However, this is the sort of email that gets the most complaints and winds up being the least wanted overall.

(Some of it will be genuine spam from genuine spammers; some will just be newsletters or helpful notices or the like that people forgot about, no longer want, or didn't realize that they were signing up to.)

Or in short: the people who most need their email certified as good are the people who's email has the highest chance of being unwanted. This does not exactly create a strong motivation for people to accept the certification.

spam/CertifiedMailProblemII written at 23:19:33; Add Comment

How your fileservers can wind up spreading over your SAN

Consider a fileserver and SAN environment where you have a number of frontend NFS fileservers and a number of backend SAN disk units, with at least as many backend disk units as fileservers. The obvious sensible way to split the disk units among the fileservers is to have each SAN unit used by only one fileserver, because that makes various things much easier to manage.

(You might even be tempted to design an infrastructure around the assumption that disk units won't be shared.)

The problem with staying this way is that you can wind up with a fileserver that has enough activity to overload its SAN disk units, because you may not know in advance what filesystems will be significantly active. To fix the issue, you need to move some active filesystems to other disk units, rebalancing the IO loads among them.

If you want to avoid user-visible disturbances, you generally can't do this by moving filesystems to another fileserver, but a well designed storage setup will let you do it by migrating the filesystem's storage to another disk unit on its current fileserver. In this case that means getting some free disk space from a less loaded SAN disk unit that normally belongs to another fileserver, since we're assuming that all of the fileserver's proper disk units are overloaded already.

Presto: you have SAN disk units that are shared between multiple fileservers, and your fileservers can potentially wind up spreading across many (or all) of your SAN disk units.

tech/SANSpread written at 01:03:31; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.