I’ve been thinking about code review lately, and took a little time to look at the Linux kernel git tree to see how many commits are marked with “Reviewed-by” (indicates that the patch has been reviewed and found acceptable). The short answer is, not a whole lot – or at least not consistently, but improving. Continue reading
I got a refurbed Cisco X2000
Edit: Everything else is bad! Don’t get this device. Really. It’s the buggiest piece of junk I’ve had the misfortune of trying to run on my network. I’ll leave the rest of this post here for posterity.
Ok, this is a pretty utilitarian post. I did finally get my 18W Server up and running; in fact, it’s serving this post! But I can’t really get to 18W unless the 2x 2T WD20EARS [amzn] drives I have in it for media storage spin down when not in use.
And I had a heck of a time making that work. hdparm -y would quickly spin them down, but using hdparm -S to set an idle timeout seemed to have no effect; I had been trying to use hdparm -S 241 to set a 30 minute spindown time, and I had no luck whatsoever. With the drives spinning, the server used more like 30W.
Mostly through trial and error, I found out that if you set a lower spindown timeout, i.e. hdparm -S 3, the drive will spin down in 10 minutes. Continue reading
I did a post last year about how lines of code for some of the primary Linux filesystems were evolving. It seemed to spark people’s interest, so here’s an update through v3.4-rc4:
(Click to see full size).
I added regression lines this time – btrfs should catch xfs around kernel version 3.8 or so. :)
Again, I draw no strong conclusions from this – I just think it’s interesting to see how things are moving as these filesystems evolve.
I used CLOC to count lines; the numbers on the graph reflect no blank lines & no comments. For ext3 & ext4 I included jbd[2] and some of the peripheral files they use; code snippet from the script:
ext3lines=`cloc fs/ext3/*.[ch] include/linux/ext3*.h fs/jbd/*.[ch] \
include/linux/jbd.h fs/mbcache.c include/linux/mbcache.h \
| grep SUM | awk '{print $5}'`;
ext4lines=`cloc fs/ext4/*.[ch] include/linux/ext4*.h fs/jbd2/*.[ch] \
include/linux/jbd2.h fs/mbcache.c include/linux/mbcache.h \
| grep SUM | awk '{print $5}'`;
xfslines=`cloc fs/xfs/*.[ch] fs/xfs/*/*.[ch] include/linux/dqblk_xfs.h \
| grep SUM | awk '{print $5}'`;
btrfslines=`cloc fs/btrfs/*.[ch] | grep SUM | awk '{print $5}'`;
gfs2lines=`cloc fs/gfs2/*.[ch] include/linux/gfs2* \
| grep SUM | awk '{print $5}'`;
(Some of the files above no longer exist, but I used the same script to iterate over all the kernel versions.)
Can you build a Linux server for web, email, printing, and 4 terabytes of media serving purposes from commodity x86 parts, and come in under 20W? Absolutely! Continue reading
The XFS filesystem has taken a beating for being a big, complicated, foreign filesystem since it’s introduction, and there is no doubt that there is a fair bit of code in there. But an interesting thing happened on the way to the Linux Kernel v3.0.0 - XFS developers have steadily reduced lines of code, while other up and coming filesystems such as Ext4 and BTRFS are steadily growing in LOC and complexity. And XFS has been under constant improvement at the same time as well.
Some of this is to be expected when comparing a mature product to newer developments, but I still find it interesting.
Notes on the above graph :
XFS is actually more heavily commented than EXT4 or BTRFS; XFS is about 39% comments, while EXT4 is about 33% and BTRFS is about 17%.
Another interesting metric is to use Simian to see how much duplicated code there might be:
Those high-level numbers aren’t terribly useful, but digging into them sometimes reveals a surprising amount of cut+paste in the course of development.
Other duplicate finders such as duplo and CPD are useful, too – these latter have free licenses. They all behave a little bit differently…
(edit: Many of the xfs dups are actually a result of the many explicit #include directives in each C file).
I didn’t intentionally change the layout… EPEL sprung a WordPress 3.1 upgrade on me, and it seems the old theme is gone (in addition to needing a database upgrade before anything would even display, bleah!) So you’ll have to stare at the lonely guy walking down the country road until I find something I like better.
Once a year or so I actually write something about computers… ;)
Continue reading
One of the legs of the main mirror of this box was starting to throw SMART errrors, and that makes me nervous, even when I can remap the sectors. So when life gives you lemons, make lemonade! I replaced the main root mirror with a couple new drives – 7200RPM seagate 250G laptop drives, on sale from newegg, the pair $90 with free shipping.
And now, the Kill A Watt
Update: I’ve since built a box with a mobile atom CPU which fares much better, as described in this post.
So I was all fired up to lower the power consumption of sandeen.net, the humble server upon which you read this blog. (And thank you for that, by the way. You can count yourselves among the 3 finest people on the internet.)
I decided to swap out the old AMD Athlon for an Intel Atom – you know, that low-power, lower-performance wonder-chip from Intel. I ordered a Gigabyte GA-D510UD from newegg.com, for $90… it looked interesting because it had 4 SATA ports built-in, which should suffice for any amount of storage that I’d likely have connected directly to it.
sandeen.net draws about 51W, which is really not too bad considering there are 2 active drives in it (a mirror) and one sleeping drive that gets backups occasionally. It’s a AMD Athlon(tm) 64 Processor 3400+ in an old Compaq SR1710NX that I got cheap 5 years ago or so, and updated the cpu, memory, drives, etc… These new low-power Atoms must be really great then, right?
So it gets here Friday, and I’m all excited… I take down the server, plug it in, and well, first off RHEL5 was not happy with it, bringing the drives up as /dev/hda, /dev/hdb… (remember those?), and and after a bit of fiddling to get the config right I decide to just put things back as they were, and play with the board offline. Before doing so, I check the Kill A Watt
So I put the RHEL6 beta on it, and get it all fired up, and re-check … hm, nope, still 36W or so with a single drive, subtract out that 8W, the board is pulling around 27W. This is not the low power I’d hoped for! So I start digging – oh look, the chip doesn’t support any P-states, and only 2 C-states:
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0.3%) 1.67 Ghz 100.0%
polling 0.0ms ( 0.0%)
C1 137.5ms (99.7%)
And sure enough, checking the Intel docs, only the chips designed for mobile use have the nice power features.
In short, the shiny new low-power Atom sure appears to use just as much power as my 5-year-old run of the mill AMD Athlon64 (in a low P-state, granted). Sure, at full-tilt maybe it’s using less, but it runs at full-tilt all the time and my Athlon is able to throttle back almost all the time.
I’ll eat the restocking & shipping and send this thing back to newegg, bitterly disappointed.
I have higher hopes for swapping out the hard drives (one leg of the mirror is dying) to WD Caviar Green drives – I can save about 8kWh/month with those if the specs are accurate. :)
