[Pkg-ganeti-devel] Bug#782073: ganeti: Refuses to work with (extstorage) disk devices if they have a high minor number

[Apollon Oikonomopoulos]

Control: clone -1 -2
Control: retitle -2 python: os.minor()/os.major() do not support large device major/minor numbers
Control: reassign -2 python2.7
Control: severity -2 normal
Control: tags -2 upstream
Control: tags -1 upstream
Control: forwarded -1 https://code.google.com/p/ganeti/issues/detail?id=1058

Hi Joerg,

On 13:54 Tue 07 Apr     , Joerg Jaspert wrote:
> What happened is that the extstorage scripts nicely setup the new md
> device. The automagic numbering made /dev/md/$VOL_NAME a link to
> /dev/md1048575. a device which has the major of 9, and minor of 1048575:
> 
> brw-rw---T 1 root disk   9, 1048575 Apr  7 12:58 /dev/md1048575
> 
> 
> ganetis storage scripts now seem to do an "os.minor()" on the device,
> and that emits the error. Whyever it does this, i don't see why it
> should be more picky than the entire system around. The kernel is
> happy, the block layer is happy, md loves it, just ganeti hates it.
> While it may be argued that this is pythons fault being silly here, I
> think fixing ganeti to be able to still work is a good thing.

This is indeed a Python bug. Python uses the following definition for 
os.minor():

   def minor(dev): return ((int)((dev) & 0xff))

while glibc's current definition is:

   return (__dev & 0xff) | ((unsigned int) (__dev >> 12) & ~0xff);

The same goes for os.major():

  def major(dev): return ((int)(((dev) >> 8) & 0xff))

vs

  return ((__dev >> 8) & 0xfff) | ((unsigned int) (__dev >> 32) & ~0xfff);

Note that device numbers have been 32-bit quantities since Linux 2.6.0. In this
case, the device has an st_rdev number of 4293921279.

I agree with you that it's easier for Ganeti to work around this bug at 
this point, so I've forwarded it upstream. Still, I'm cloning this as a 
Python bug as well, at least for future reference.

Regards,
Apollon