Josef “Jeff” Sipek

Wow…just wow. The article says it all.

Oh, by the way, it looks like this robber is holding it by the blade…jeez.

Today, I got to use z/VM 5.2 a whole lot (well, I didn’t do all that much, but considering that I never typed a single command in z/VM — only VM/370 — it was a whole lot of using :) ). Long story, short, z/VM is totally amazingly awesome.

Here’s an image that I found on IBM’s website:

I decided to clean out my room aaaand I found this:

I vaguely remember hearing that it was an ancient storage device of some sort… :)

Last night, I forget who, challenged me to make a smilie with disk io and seekwatcher. Well, I couldn’t let such challenge just pass me by (click to enlarge):

All that I used was: blktrace, seekwatcher, python (to do the math - sin, cos, etc.), and dd (to do the disk io). I am already planning bigger and better things :)

Today I was playing with blktrace, and graphing the results with seekwatcher. At one point, I ran acp (which is a lot like tar, but tries to be smarter) on a directory stored on an XFS volume, but I forgot that months ago, I created a sparse file 101PB (that’s peta) in size. Well, acp was happily reading all the sparse regions. I killed it, and decided to remove the gigantic file which was totally useless. About 30 seconds into the removal, I realized it would have been great to have a trace of that. Well, I started blktrace and about 12 minutes later the rm process finished.

I graphed it and here’s the result (click for larger version):

At first I was very confused why things looked the way they did, but eventually it dawned on me (after some discussion with Dave Chinner — XFS dude) that it’s all journal log traffic. I quickly ran xfs_info on the filesystem:

meta-data=/dev/sdb1              isize=256    agcount=16, agsize=1120031 blks
         =                       sectsz=512   attr=1
data     =                       bsize=4096   blocks=17920496, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=8750, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

And things just made sense. I calculated the size of the log (see bolded numbers) to be (4096*8750) bytes, or 34.17 MB (base 2) or 35.84 MB (base 10). If you look at the graph, you’ll see that the disk offsets accessed were 35001 to 35035 MB or about 35MB! XFS puts the log near the middle of the disk to minimize seeks as much as possible, so as you may have guessed, my disk is about 70GB in size (it’s a U160 73GB SCSI disk).

I stumbled on this few days ago. It has been said that a picture is worth a thousand words, so here’s one (shamelessly stolen from the link above):

So, today was interesting. Some of the people I saw and/or talked with included: Andrew Morton, Alan Cox, Dave Jones, Jim Gettys, Matt Mackall, and so many others I don’t even remember.

When I got back to the hotel, I noticed this one interesting sign on it (on the inside), I couldn’t resist to take a photo of it. Here’s a cropped portion of it that has the amusing part (there was presumably the same text in French as well as a map to the nearest emergency exit):

So, yeah. I finally forced myself to write one of these blog entries. Woohoo! I’ve been quite busy for the past two weeks (doing some cluster building, and then slideshow making - I leave for OLS in only 4 days!) I must say it should be interesting - the presentation, the impromptu stackable filesystems BOF.

I just found this very bizarre image (mirror) (too wide to include it here) which explains rather humorously  RAID.

So, few days ago Wikipedia’s Picture of The Day was a photo of Wernher von Braun standing next to 5 F-1 Engines. I still can’t get over how awesome the photo is. Here’s what it looks like:

I came across this image, which clearly illustrates the twisted nature of Emacs, and the "kick ass" aspect of Vi/Vim.