kernel 2.6.36-gentoo-r5 only recognize up to 136.9GB VHD?

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

Hello,

I have migrated my gentoo server to a MS Hyper-V VM and only had to add
Device Drivers>
CMD64x PATA support

to the kernel configuration in order to get the system to boot. Without that I was getting kernel panic about VFS not being about to mount root...

The problem I have now is that I have two VHD sda and sdb. So far sda 73GB seems to be working fine and it where the OS is. I also have sdb 600GB and for whatever reason is only recognized as 136.9GB.

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

Well. Its a year old but this looks pretty close to my problem.
http://www.serverphorums.com/read.php?12,79638

NeddySeagoon · Posted: Fri Dec 24, 2010 12:39 am Post subject:

yaplej,

Something somewhere is not using 48bit Logical Block Addressing. The driver plays no part in that. 48 bit LBA has been in the kernel since before real drives reached 137G.
Check in the Virtual BIOS to see what options you have there.

Is the Emulated CMD64x PATA chip set your only choice?
The real CMD64x is probably the worst chip set in the world. It doesn't even support DMA trasfers.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

Well it does not even seem to be using the CMD64X driver so I dont know if my fooling around in the ATA/ATAPI/MFM/RLL section can also change settings in the Serial ATA and Parallel ATAPI drivers section also. I have removed the CMD64X driver and building a new kernel. I first tried enabling CMD640 in ATA/ATAPI/MFM/RLL. It also enabled a bunch of chipsets but then went back to using Serial ATA and it also worked so I didnt know if enablishing a driver under one section would carry over into another.

NeddySeagoon · Posted: Mon Dec 27, 2010 7:32 pm Post subject:

yaplej,

The

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

I tried to disable all other chipsets as in the guide but the VHD is still only detected as 136.9GB. Perhaps there is something else in my .config that is conflicting?

http://pastebin.com/6CNfDZZc

NeddySeagoon · Posted: Tue Dec 28, 2010 2:31 pm Post subject:

yaplej,

Your kernel looks ok.
Google suggests that the 137G limit is a feature of MS Hyper-V

There are two workarounds - make more smaller virtual drives and stick them together either with linear raid0 or with LVM.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

I have been reading a lot and Hyper-V R2 should use LBA48 for the ATA interface and VHDs. The 127GB limit was in Virtual Server product and was increased to 2048GB when they introduced Hyper-V.
http://social.technet.microsoft.com/Forums/en/winserverhyperv/thread/f5784096-808b-4a66-9bfd-fecb0a0946cc

This system was upgraded from kernel 2.6.11 and with that kernel it could see this 600GB VHD although it was hdb rather than sdb due to the older chipset drivers. There has been so many changes from then it might be difficult at best to figure out why the older worked and the newer does not.

There was some mention that Linux might not be reading the VHD geometry correctly. I dont know if there is much merrit to that.

Another solution was to use the Hyper-V drivers and connect the VHD with the Hyper-V SCSI interface. I have read that some people were able to access larger VHDs using that method. The problem I have is the modules seem to crash the system when I insmod them. Perhaps thats another thread though.

I still think this is the same issue that was discused back in 2009 here http://www.serverphorums.com/read.php?12,79638. Going over the commands they checked in that discussion the drive is being read as 136GB.

NeddySeagoon · Posted: Tue Dec 28, 2010 7:37 pm Post subject:

yaplej,

Linux had never cared about HDD geometery, its always used LBA.
When drives reached around 4Gb, geometery was a myth perpretrated by hard drives for uses of DOS based OS, like Windows as far as Windows 98.
At around 4G, HDD became zoned, so different zones have a different number of sectors per track. This makes better use of the platter surface since outer tracks can store more sectors pert track then inner tracks. The effect is easy to detect - try sequential read speed tests near the outside and inside the of the disk. There is about a 2:1 difference.

The 137Gb limit is the VM not reporting any data in the LBA48 field of the IDE drive identify command, so linux uses the LBA28 data, which is correctly maxed out at 133Gb.
This is non compliant with the IDE standard which requires HDD > 137G to populate the LBA48 field.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

Thanks for clarifying that. Like I said I didnt know if there was any merrit to that.

This has me wondering though why back in kernel 2.6.11 it worked and now in 2.6.36 it does not. I guess we can assume Windows would read the LBA fields just like Linux would I mean hardware is hardware even if its emulated or not right? So I created a new VM with a single 400GB VHD connection to the IDE interface. After installing Windows XP Pro and it was able to recognize the full 400GB. Widows does not count though so I then tried CentOS 5.4 i386 and it also can see it as a full 400GB. I did noticed that in CentOS the VHD was reported as hda rather than sda and found CentOS is using kernel 2.6.18 so that explains why it can access the full 400GB drive because it seemed to work before 2.6.28.

I think your right that the only way around this right now is to use LVM or raid 0 with multiple drives. At least that way I can get this project moving along and my data online again.

NeddySeagoon · Posted: Tue Dec 28, 2010 9:55 pm Post subject:

yaplej,

In a VM the hard drive is emulated. If the emulated response to the identify command is incomplete/incorrect - its the emulator that is broken.
The idea is that the guest can't tell the difference between real hardware and the VM. In this case, it can.

The old IDE kernel branch used to have some options to make it more tolerant of malformed identify responses but its gone on 2.6.36.
I've not used the IDE branch since 2.6.23. I have no idea when it went away.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

Thanks.

It makes sense if the older kernel was more tolerent of the emulation oddities. The SCSI interface does seems to work for VHD > 137GB if I can get the hv modules to work with any sort of consistency/stability.

NeddySeagoon · Posted: Tue Dec 28, 2010 11:55 pm Post subject:

yaplej,

It may have been more tolerant od drive oddities. The kernel is not supposed to be able to tell its in a VM and not on bare hardware.

I don't know if the option was removed, so there is now no user control or if it was automated somehow.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

yaplej · n00b Joined: 15 Dec 2010 Posts: 22

Well I think this is SOLVED the IDE interface emulation in Hyper-V seems to have broken LBA48 support. SCSI emulation works but is not stable at least in my playing around with it. If I can get the system to boot with the hv modules it can access a VHD > 137GB but getting the system to boot with the hv modules has been difficult and inconsistent at best.