What causes the ZFS file deletion problem with snapshots
Suppose that you have a ZFS pool that you have filled utterly up to thebrim, completely full, and that it has a snapshot. Of course, now youneed to delete some files in a filesystem to clean up space, so:
$ rm oldfile
rm: cannot remove `oldfile': No space left on device
(Here oldfile is a file that is old enough to be in the snapshot.)
The ultimate cause of this is a general problem with 'copy on write'filesystems such as ZFS.
The problem with Solaris 10 update 6's ZFS failmode setting
After I was so negative on ZFS's new failmode setting , one might sensibly ask what the problem with it is.
(Background: the ZFS failmode setting controls what happens whenZFS can't perform IO to a pool because the pool has totally lostredundancy. It has three settings, one to panic your system (just likethe old behavior ), one to block all IO until thedevices recover, and one to continue as much as possible.)
The problem that I observed in our iSCSI based environment
How I went wrong in thinking about /boot mirroring
I've always seen how a mirrored /boot could work if the disks wereabsolutely identical up to the end of the /boot partition; if theywere identical, the absolute block positions of everything that the bootblocks wanted to load would be identical, so nothing would care aboutwhich disk it was talking to. My concern was always what happened if thedisks weren't quite so utterly identical, because back in the day itseemed to me like that required quite a lot of magic.
(I'
Your ticketing system should be optional
There's a fair bit of enthusiasm for ticketing systems in the sysadminworld, and it's not hard to see why. But I'm going to be a contrarianhere: while ticketing systems are all well and good, you shouldabsolutely not require users to use them in order to interact with you.
The problem with ticketing systems is that they're like bug trackers ; they're internal systems that are almostalways filled with fields and procedures that exist for your needs.Your users should not
A hairshirt too far: on always avoiding CSS
Recently I wound up reading the Weblessinitiative ( via ), which advocates avery strict CSS-less sort of web design. To coin a phrase, I think thatthis is a hairshirt too far; not only does it make it harder to creategood web pages, but it can damage the web viewing experience for yourvisitors.
First, I think that it's clear that 'graphics', broadly interpreted,are superior to plain monospaced text even for text content, as theyallow you to do important
The advantage of having an (XML) sitemap
I've had a sitemap for a fairly longtime (long enough that the format changed out from under me a fewtimes). In theory I created it for Google, as a way of steeringthem around WanderingThoughts (and CSpace as a whole), but I'venever been sure if Google was really getting anything out of it.As it turns out, that doesn't really matter, because having asitemap has turned out to be really useful for me.
Why it's so useful
Why 'sender stores message' is easier for spammers than real mail servers
In my first entry on 'sender stores message'schemes for email, I asserted that spammers would have no problem makingsure that their servers are not crushed under the load of everyonetrying to read the spam email from them, yet in SenderStorageProblems Isaid that real mail senders would have such problems.The difference is that the two groups have very different problems, andthe spammers can cheat. Let's look at what the two look like.
Real mail servers of any significant size will be dealing with tensof
Why ssh needs to verify host keys
Suppose that your ssh does not check host keys and an attacker has notso much successfully impersonated one of your machines as persuadedyou to connect to his machine instead of yours, without you knowing.How does the attacker 'win'?
We can see the obvious wins by what ssh turns off if you have StrictHostKeyChecking set to 'no' and a key fails to verify. First,the attacker wins immediately if they can get you to type your passwordto their ssh daemon, since they can just have their ssh
The technical problems with 'sender stores messages' schemes
For some reason, people have an enduring like for new schemes foremail where the sender stores the message until the recipient wants toread it (the most well known is D. J. Bernstein's Internet Mail 2000 ). Such schemes tend to handwave the socialproblems involved in a transition, but let's set that aside (alongwith why they won't stop spam ) and talk aboutthe practical technical problems, because from my perspective they arepretty bad.
If the sender stores
Handling ssh to generic hostnames
(This idea is not from me, it's from R Francis Smith . It is just sufficiently nifty and wrong thatI'm going to write it up for posterity.)
Suppose that you have a generic hostname, a hostname that either ismultiple machines (with multiple IP addresses) or a virtual host thatgets pointed to different physical machines from time to time. Furthersuppose that inside your environment, your users ssh to that machine,or at least want to. The traditional problem with this is that