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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
