Return of the low-power server: a 10W, 6.5 terabyte, commodity x86 Linux box

5 years ago, I wrote about the build of the server hosting, which ran using only 18W of power.  After 5 years, it was time for an upgrade, and I’m pleased to say that I put together a much more capable system which now runs at only 10W!  This system handles external email and webserving, as well as handling media serving, energy datalogging, and backup storage for household purposes.  It’s the server which dished up this blog for you today. wattage, as measured by a Kill-a-Watt meter [amzn]

Continue reading

No, XFS won’t steal your money

So, the Inquirer runs a story by Chris Merriman today, titled “GreenDispenser malware threatens to take all your dosh from Linux ATMs” which includes this breathless little gem:

GreenDispenser targets the XFS file system, a popular standard for ATMs, originally designed for IRIX but now widely used in Linux. ATMs that use Windows XP Embedded, which is still supported, are not thought to be at risk.

Of course, I found this interesting, and a bit odd.  Could the XFS filesystem possibly be at fault here?  And is the “large and lots” filesystem really used in ATMS?  Let’s see what Proofpoint, the security firm who discovered it has to say about the subject:

Specifically, GreenDispenser like its predecessors interacts with the XFS middleware [4], which is widely adopted by various ATM vendors.

That handy link & footnote leads us to Wikipedia, which explains that “XFS middleware” refers to CEN/XFS, which is not in any way related to the XFS filesystem, or Linux, and is in fact Microsoft specific:

CEN/XFS or XFS (eXtensions for Financial Services) provides a client-server architecture for financial applications on the Microsoft Windows platform.

Nice job, Inquirer!  Nice job, Chris Merriman!

(As Jeff points out in the comments, The Inquirer has updated the article as of Sep 25, removing references to LInux and the XFS filesystem.)

Sage’s challenge to the open storage community – support the Ada Iniative!

The Ada Initiative supports women in open technology and culture – looking around my place of work and various conference halls I’ve visited, I think there’s little doubt that we’ve still got an old boy network running here, and I’d like to see that change.  I have daughters who may or may not get deep into tech culture, and I’m glad there are people like Val working to make it a better place for them if they do.

And she’s recently gotten a nice bit of potential help: Sage Weil of Ceph & Dreamhost fame has issued a challenge: Raise $8192 in 8 days, and he’ll match it.  They’re already on their way.  If you can help, please do.  Power-of-two donations encouraged, but not required.  :) Click the counter below to see their donation page.  Thanks!

Donate now

Uncompressing Cisco X2000 firmware images

I got a refurbed Cisco X2000 [amzn] ADSL router / wireless access point for cheap from Adorama, hoping to combine 2 networking boxes, and reduce clutter and power a bit.  It comes in at 3-4W, and has an efficiency Level V wall wart, so that part’s all good.

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.

Continue reading

Spinning down a WD20EARS “Green” drive

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

Linux Filesystems LOC Update

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.)

Linux Filesystems LOC

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 :

  • Comments & whitespace were stripped with CLOC for LOC counts
  • EXT4 LOC includes jbd2 as well.

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:

  • xfs: Found 4806 duplicate lines in 561 blocks in 55 files
  • ext4+jbd2: Found 917 duplicate lines in 116 blocks in 23 files
  • btrfs: Found 2252 duplicate lines in 272 blocks in 31 files

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).

New look

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.