CentOS 6.4 SSD RAID-1 /w TRIM support
Tuesday, April 2. 2013
The short version is: it does not work.
Having a SSD is feasible in the long run only if there is possibility of operating system informing the drive that an entire drive block (typically 16 KiB) can be erased. openSUSE wiki has following quote in it: "There are three terms often used to interchangeably describe this same basic functionality: Discard, UNMAP, and TRIM." This discard is possible only when there are no operating system sectors (typically 512 bytes) in the drive block.
Here is what I tried to do: I installed two IntelĀ® Solid-State Drive 520 Series drives into my server and tried to see if RedHat-based CentOS 6.4 has enough backported bits & pieces to support RAID-1 /w TRIM.
The drives are fine and kernel TRIM-support is there:
hdparm -I /dev/sda | fgrep -i trim
* Data Set Management TRIM supported
* Deterministic read after TRIM
My initial attempt had GPT-partition table with a single RAID-partition on it. The command I used is:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
I created EXT-4 on top of md0:
mkfs.ext4 /dev/md0
and mounted it:
mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime
The discard-support is in the kernel ok:
mount | fgrep md0
/dev/md0 on /mnt/tmp type ext4 (rw,noatime,nodiratime,discard)
The next thing I tried to do is confirm if TRIM does work either automatically or as a batch job. I followed instructions from this blog entry and tried to run hdparm --fibmap on a newly created file. It failed with a segfault. Apparently that is a known issue, so I ended up packaging the latest version myself. My own RPM-package is available at http://opensource.hqcodeshop.com/CentOS/6%20x86_64/hdparm-9.43-1.el6.x86_64.rpm.
With latest hdparm 9.43 I could verify that FIEMAP (file extent map) ioctl() does not return correct results on a soft-RAID-1 device. The LBA-sector given by hdparm does not seem to contain the file's data.
My next attempt was to tear down the existing md0 and re-build it using entire drive as RAID-device.
mdadm --stop /dev/md0
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime
I ran the same test, but this time hdparm --fibmap informed it failed to determine the drive geometry correctly. A short peek into the source code revealed that current version of hdparm works only with partitions. It tries to load the RAID-partition start LBA even if it is not located on a partition. I made a quick fix for that, it turned out that /sys/block/md0/md/rd0/block has DEVTYPE=disk or DEVTYPE=partition to indicate the base drive type.
Nevertheless, it did not help. fibmap does not return the correct LBA-sector. I loaded a Bash-script to do the manual TRIMming of a SSD-RAID-1, but it only confirmed what I already knew. The LBA-mapping does not work enough to see if discard works or not.
Currently I don't have anything on my RAID-1, I'll have to see if it is possible to get the discard working somehow. A newer Linux might do the trick.
Open recursive DNS-resolvers
Tuesday, April 2. 2013
Since the enemy had some help, what happened next was Spamhaus joining forces with Cloudflare, a company specializing in mitigating the effects of a DDoS-attack. What happened at the end of March 2013 has been described as "The DDoS That Almost Broke the Internet" by Cloudflare blog.
The spam-blocking service Spamhaus is providing technically works on top of DNS. Anybody running a receiving mail-server can configure it to confirm the connecting client's IP-address with a simple DNS-query returning funny-but-pre-determined names as an answer to determine the "spamminess" level of connecting client. The judgement who is a spammer and who is not is made solely by the Spamhaus. That's what the dispute between them and Cyberbunker is all about.
As described by Cloudflare, technically Cyberbunker's (alleged) DDoS works by amplifying incoming 36 UDP-bytes containing a valid query for RIPE.net's zone into 100-fold. There are at least 30.000 open DNS-servers responding to recursive queries. All they have to do is spoof the original UDP-packet's sender's IP into Spamhaus and they have harnessed a huge Internet traffic amplification machine targeting a single IP-address.
Since I myself am running a couple of DNS-boxes, I wanted to re-verify my servers, that they cannot be used into such activity. I googled some and found The Measurement Factory's Open resolver test. That appears to be a piece of crap. You punch in an IP-address and get open/closed status as a response. You can enter any invented IP-address to get the closed-verdict. WTF?!
The second thing I found is much convincing: Open DNS Resolver Project. The problem with that one is, that they just browse The Net and try to find open DNS-servers. For example my boxes were not listed. Not as open, closed or existing. They don't publish information about properly configured DNS-servers. It still leaves the original question unanswered: Can my DNS-server be used for attacking innocent or not.
Here is my answer to the problem: http://opensource.hqcodeshop.com/DNStest/dnstest-cgi.pl
It caches the result of any query for 24 hours, and cannot be used for bullying somebody. That feature I simply stole copied from The Measurement Factory. Its fully written in Perl and even the source code is available for you to get.
Initial feedback after putting the thing on-line was to support FQDNs. The answer is NO. My thing won't do any unnecessary DNS-requests, if possible. But if you have any other suggestions, please drop a comment.