48-bit LBA in VL 5.8 Standard

[GrannyGeek]

What kind of support for 48-bit LBA does VL5.8 Standard Gold have?

I ran into a situation I'm trying to figure out. I recently replaced a 200-gig IDE drive with a 500-gig drive. I have a 135-gig partition for VL 5.8 Standard on that drive. There are also a FAT32 partition and an NTFS partition shared with Windows XP. Everything is working fine on the internal drive.

I put the removed 200-gig drive into a USB2 external case. My intent was to use a Linux file system on the entire drive and use it for backups. With cfdisk I created an extended partition and filled all of it with a single Linux logical partition. I then formatted the partition with mkfs.reiserfs.

When I replugged the formatted drive, vl-hot recognized it as /mnt/vl-hot/sdf/vol5 (I think). I then attempted to copy my QEMU virtual machine files to the external drive. I have a 30-gig QEMU virtual machine in which Windows 98SE is installed. I first attempted to copy the file using Midnight Commander. The copying proceeded but the speed was quite slow. Toward the end of the process, the copy function discontinued and the file was not copied. In order to see error messages, I then tried to copy using a cp command. I got error messages almost immediately. I was not able to interrupt the process and get a command prompt, nor could I unmount the drive. I could not reboot with Control-Alt-Delete. I had to turn off the computer in order to stop whatever was going on (copying to the external drive was not happening because the light on the drive that shows disk activity was not flashing).

After more failed attempts, I decided to troubleshoot the drive, so I copied the 30-gig files (the working file and a backup) to an NTFS partition (my Windows Drive I). Then I rebooted into XP and reformatted the entire external drive with NTFS. I then copied the QEMU virtual machine files from the NTFS Drive I to the NTFS external drive. The copying completed with no problems. I then ran chkdsk with a surface test on the external drive, and there were no errors.

Okay, the drive is fine and I can copy huge files to a single 200-gig partition (XP and my BIOS support 48-bit LBA). So I booted with my Beryl LiveCD and used cfdisk to wipe out the NTFS partition and create *two* Linux partitions on the 200-gig drive: one about 120 gigs and the other 70-some gigs. I then used Gparted to format both partitions with ext3.

I rebooted into my VL 5.8 Standard Gold installation and the partitions were seen and mounted by vl-hot. I then copied two 30-gig QEMU virtual machine files into the external drive's 70-gig partition. The copying completed without errors and the speed was very good.

So.....
I'm wondering why I had the problems when I had a single 200-gig reiserfs partition on the external drive. I didn't want to have a partition over 137 gigs on my second attempt "just in case" 48-bit LBA support is not up to snuff in VL 5.8 Standard. I also used ext3 instead of reiserfs on my successful attempt. "Fool me once, shame on you. Fool me twice, shame on me."<g>
--GrannyGeek

[Joe1962]

Never thought about this before, but a quick search gave this:

http://www.cgsecurity.org/wiki/OS_Notes

Linux and 48-bit LBA

Linux kernels since at least 2.4.19 have been able to access Large disks (drives over 137 GB using 48-bit LBA); and some earlier kernels, such as Red Hat 7.3's 2.4.18-x, were patched, so check the specific features of your install to know for sure. Linux kernels 2.2.x and older are limited to only 65,535 cylinders.

Beyond that, I didn't find any mention of having to switch on the support. There is however a switch in the kernel config for "Support for Large Block Devices" (for discs > 2 terabytes), which is enabled in the stock 5.8 Standard kernel.

[GrannyGeek]

I sent my message by accident before I finished it. I edited it to add all the grim details.

I figured 48-bit LBA was almost certainly supported. It was the first thing that came to mind as a possible explanation for the problem I had.

I wonder if I didn't do the original formatting properly. After I set up the single partition with cfdisk, I used the mkfs.reiserfs command to install a file system on the partition. I have a feeling something didn't go right because the formatting took about five seconds, which is faster than I've ever experienced formatting regardless of operating system. That should have made me suspicious.

I suppose I could start all over by wiping the 200-gig external drive, partitioning it with a single partition, and formatting with reiserfs or ext3 and then seeing what happens if I copy the 30-gig QEMU file to the drive. Maybe if I have a lot of time on my hands someday...
--GrannyGeek