Thursday, June 26, 2014

CDS Giant and Hammer

Today is the second day of the Ceph Developer Summit (CDS) for the Giant and Hammer release. We had already several interesting topics and discussions yesterday on the first day.

It's 01:00 in CEST, so now is the time for you to join if you are interested! Find all information and the link to the video conference here!

Thursday, February 27, 2014

rbd ioengine for fio

Since running benchmarks against Ceph was a topic in the "Best Practices with Ceph as Distributed, Intelligent, Unified Cloud Storage (Dieter Kasper, Fujitsu)" talk on the Ceph day in Frankfurt today, I would like to point you to a blog post about the outcome of the time we spend on benchmarking Ceph performance to find bottlenecks at the Platform Engineering team for the Business Marketplace at Deutsche Telekom AG: "Ceph Performance Analysis: fio and RBD"

Short summary: We contributed a rbd engine swiss-knife-IO-tool fio. You are now able to run tests directly against the userspace librbd implementation as e.g. used by RBD QEMU driver. This allows you to have one single IO benchmark tool to run against RBD kernel, the userspace implementation or against a RBD block device directly in your VM.

Ceph Day 2014 in Frankfurt

Back again on my blog ... as you may know I work since a while now on the topic of Cloud Storage and especially on Ceph. I didn't add new posts about this topic since a long time, but I plan to do so.

Today (2014-02-27) I'm in Frankfurt/M (Germany) to attend to the Ceph day.

 
There are several interesting talks/presentations on the agenda like "Best Practices with Ceph as Distributed, Intelligent, Unified Cloud Storage (Dieter Kasper, Fujitsu)" or "Ceph Performance & Optimization" (since I worked on this topic the last few months, I would like to see how others handled this challenge). I'm looking forward to meet again some of the Inktank guys I've worked with so far, some of my former SUSE colleagues and may some other Ceph community members.

Thursday, November 15, 2012

My new openSUSE buildservice home project

Only a short information for you: I have a new home project on the openSUSE buildservice.  Therefore I've took the chance and deleted my old home project and a lot of old packages I've build for no longer supported (open)SUSE releases with it. 
That also means: some of the links to packages in this blog are may broken and I don't plan to fix them. You can find the new project here. Since the most of my former packages already moved into the distribution or other devel projects feel free to search here for them if you can't find them in my new home.

Tuesday, February 07, 2012

PandaBoard: persistant MAC address via initrd

I worked out a solution to replace the random MAC address set by the smsc95xx kernel module with the MAC address generated by u-boot on the PandaBoard(ES). It should also work on the BeagleBoard.

As first you need this kernel patch to fix isses with exporting the assign type (PERM, RANDOM, STOLEN) to /sys/class/net/*/addr_assign_type correctly if the smsc95xx driver generate a random MAC address. Build your kernel, if you use openSUSE:Factory:ARM you can get RPMs here, until it's integrated into the official openSUSE kernel.

Now you need a mkinitrd with this patch or a you install these RPMs for openSUSE. This adds a initrd boot script to set the MAC address from kernel cmdline parameters. These are the available parameters and some example values:
  • setmac.set_mac_addr=01:23:45:67:89:ab
  • setmac.set_iface=eth0
  • setmac.set_module=smsc95xx
The setmac.set_mac_addr= is mandatory to change the MAC and you have to choose one of the other two parameters. Either you specify the network interface or the kernel driver/module. In case you use setmac.set_module the first network device provided by this module which has a random MAC gets the new address assigned. Please note: this script change the MAC of a interface only if addr_assign_type=1 , otherwise nothing will change.

If you have installed the new kernel and mkinitrd you may need to follow these steps:
# mount the boot partition which contains the uImage (and may also the MLO file) 
mount /dev/mmcblk0p1 /mnt
# make sure this partition contains the new uImage
# build a new initrd
mkinitrd -B
# create a uInitrd
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d /boot/initrd /mnt/uInitrd
Now you need to tell u-boot to boot from the uInitrd and to set the needed cmdline parameters. I prefer to use a uEnv.txt file instead of a boot.scr since you simply can change it without call mkimage. You can download my currently used uEnv.txt here. The content depends on your setup you may need to adapt yours:
bootargs=root=/dev/mmcblk0p2 rw rootwait rootfstype=ext3 console=ttyO2,115200n8 vram=16M omapfb.vram=0:16M
bootcmd=mmc rescan ; setenv bootargs ${bootargs} setmac.set_mac_addr="${usbethaddr}" setmac.set_iface=eth0; fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000
uenvcmd=boot
Now umount /mnt and reboot your system. If you already worked around the random MAC address problem: don't forget to remove/disable these hacks.

Monday, February 06, 2012

Personal note: Moved to blog.bisect.de

As you may already seen, I moved my blog from dkukawka.blogspot.com to a new address. You reach the blog now on blog.bisect.de . The old address should still work but you may want to adopt your bookmarks or RSS/Atom feeds. 
I also merged my blog with my Google+ profile. By this you should see new posts also at my Google+ stream.

Saturday, February 04, 2012

Update: PandaBoard persistent MAC from smsc95xx kernel module

Some days ago I decided to send an updated and reworked version of my kernel patch for the smsc95xx kernel module - to get a persistent MAC address via the kernel cmdline from u-boot - to the linux kernel mailing list. I should have known better and save me the time: the patch wasn't accepted. You can follow the discussion here.

If you follow the argumentation, we should drop the support for changing the MAC address of a network device via kernel module parameter also from e.g. the following modules: sunhme, fec or ksz884x. And we should then also remove all the 'generate a random MAC for real devices' since it all could be somehow get managed in the user-space, although it's pita to handle this task in user-space since it's currently even hard to find out if a device got a random MAC assigned from the kernel.

I still plan to add the patch to the openSUSE kernel until I've worked out another solution. Feel free to use the patch anyway on your system.