[SLE] Large Block Device Problem
I'm having trouble with a 3.6TB partition. suse creates and formats the partition fine at 3.6TB everything is fine, until reiserfsck is run at boot pukes with the following error: ########### reiserfsck --fix-fixable started at Mon Jun 5 03:35:18 2006 ########### Replaying journal.. Reiserfs journal '/dev/sda3' in blocks [18..8211]: 0 transactions replayed Zero bit found in on-disk bitmap after the last valid bit. Fixed. Checking internal tree..finished Comparing bitmaps..vpf-10630: The on-disk and the correct bitmaps differs. Will be fixed later. Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 1 Internal nodes 0 Directories 2 Other files 0 Data block pointers 0 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Mon Jun 5 03:38:07 2006 ########### donedone Somewhere in there it resizes it down to 1.7TB. I have tried other file systems also and all seem to do the same thing, xfs and ext3 anyway. Anyone have any words of wisdom to get this going? System: P4 3.0 64bit. 2 gigs of ram OpenSuse 10.1 64bit version 3ware 9550sx 64 bit pci card 12x 400GB WD hdd's. Its raid 5 with a hot spare and a 20gig / partition. Rob -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Monday 05 June 2006 16:36, Rob Sell wrote: <snip> Hi Rob, I don't have any TB partition experience, but a bit of Google and some drilling down uncovered this interesting little snippet:
The array was partitioned using the default "msdos" disk label(partition table) which doesn't support > 2Tb sizes, but the "gpt" label(table) does. Too bad the YaST partitioner doesn't make any mention of this very important info...
Could this have something to do with it? regards, Carl -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Carl Hartung wrote:
On Monday 05 June 2006 16:36, Rob Sell wrote: <snip>
Hi Rob,
I don't have any TB partition experience, but a bit of Google and some drilling down uncovered this interesting little snippet:
The array was partitioned using the default "msdos" disk label(partition table) which doesn't support > 2Tb sizes, but the "gpt" label(table) does. Too bad the YaST partitioner doesn't make any mention of this very important info...
Could this have something to do with it?
regards,
Carl
Thanks Carl. Looks like that was the problem, msdos label. had to use parted to repartition and relabel to gpt everything seems kosher now. its too bad 'partitioner' in yast2 doesn't give an option to do this. I hosed my system the first time trying to get by without fully understanding how parted works. I did have a bit of trouble with grub, had to switch to lilo, grub didn't seem to like the huge disk parameters just kept talking about disk params out of range. Rob -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Tue, 2006-06-06 at 11:27 -0500, Rob Sell wrote:
Thanks Carl. Looks like that was the problem, msdos label. had to use parted to repartition and relabel to gpt everything seems kosher now. its too bad 'partitioner' in yast2 doesn't give an option to do this. I hosed my system the first time trying to get by without fully understanding how parted works.
Just caught this thread. Yes, you can_not_ use the Legacy BIOS/DOS Disk Label (what Microsoft called "Basic" disk in NT 5.0/2000+) for >2.2TB (>2TiB) partitions. You _must_ use another disk label, such as Intel's General Partition Table (GPT). Inside the GPT you can then slice partitions as you wish, or even put in other disk labels such as BSD, LDM ("Dynamic"), LVM, etc... But understand you _can_ have boot-time issues _before_ the OS kernel boots. On a PC, the legacy BIOS Int13h Disk Services _only_ knows of the traditional 4 slice design (which Microsoft calls "Primary" in the "Basic" disk approach). So anything in the first sector of the disk -- the Master Boot Record (MBR) on the PC -- must load any additional support to do more.
I did have a bit of trouble with grub, had to switch to lilo, grub didn't seem to like the huge disk parameters just kept talking about disk params out of range.
LILO and GRUB have different approach. LILO says "boot this raw sector address" -- hence why you must install that setting before you can boot. LILO doesn't require any "advanced support" -- it only maps the OS' disk organization and device to the "raw sector address" in the bootstrap. LILO couldn't care less what organization is used -- it just has a "raw sector address" to boot. Newer LILO versions support full LBA48 addressing. GRUB says "let me read the disk and find out what I can see" -- hence why it can be changed at boot. Unfortunately, this requires that GRUB know how to read different disk labels. GRUB has yet to add support into its MBR loader for Intel GPT or Microsoft LDM disk labels. I haven't been tracking its support of Linux LVM or LVM2 either. Until a dynamic loader like GRUB gains more support for these disk labels, you're stuck either using LILO -- _or_ reserving 1-2 slices (Primary Partitions) of the legacy BIOS/DOS Disk Label for a /boot partition. For Linux systems, I typically create 3 Primary Partitions (83) of 2GB/each, and then a LVM (8E). I actually only use 1 of the Primary Partitions, and leave the other 2 in case I need to load a 'recovery' install or other 'test' install. On servers, I typically reduce Partition 1 to 256MB and load a dd image of DR-DOS 7.03 on it (for firmware updates that must run from DOS). On dual-boot Linux and Windows (NT5.0/2000+) systems, I create 2 Primary Partitions of 2GB/each, then I create a LDM Partition (42) and then a LVM (8E). Windows goes into the LDM and Linux goes into the LVM, except /boot. I still like to reserve Partition 1 for DR-DOS 7.03 -- you never know when you need a "Real86 DOS" boot for a firmware update or diagnostics. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ------------------------------------------------------- Illegal Immigration = "Representation Without Taxation" -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Tue, 2006-06-06 at 12:41 -0400, Bryan J. Smith wrote:
For Linux systems, I typically create 3 Primary Partitions (83) of 2GB/each, and then a LVM (8E). I actually only use 1 of the Primary Partitions, and leave the other 2 in case I need to load a 'recovery' install or other 'test' install. On servers, I typically reduce Partition 1 to 256MB and load a dd image of DR-DOS 7.03 on it (for firmware updates that must run from DOS). On dual-boot Linux and Windows (NT5.0/2000+) systems, I create 2 Primary Partitions of 2GB/each, then I create a LDM Partition (42) and then a LVM (8E). Windows goes into the LDM and Linux goes into the LVM, except /boot. I still like to reserve Partition 1 for DR-DOS 7.03 -- you never know when you need a "Real86 DOS" boot for a firmware update or diagnostics.
Oops, forgot the last point ... If LVM (8E) is going to be larger than 2.2TB (2TiB), then I will create a GPT and put any LVM in it. But there are some limits to LVM (not sure about LVM2) around 8.8TB (8TiB) I've run into as well. In general, I really avoid creating such large filesystems -- ext2.fsck and xfs_repair take forever on them. I almost always create at least 2-3 data volumes.** I haven't messed with LDM in GPT on x86 -- only Itanium -- which allows Windows to boot from a LDM disk label inside of a GPT using the EFT firmware. I haven't kept track of all the MacOS X on x86 developments, since it uses EFT and, therefore, GPT (IIRC), but I believe it's the same. So maybe Apple will help standardize EFT on x86 and x86-64 and GPT will be the norm for all x86 and x86-64 OSes? -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ------------------------------------------------------- Illegal Immigration = "Representation Without Taxation" -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Bryan J. Smith wrote:
I haven't messed with LDM in GPT on x86 -- only Itanium -- which allows Windows to boot from a LDM disk label inside of a GPT using the EFT firmware. I haven't kept track of all the MacOS X on x86 developments, since it uses EFT and, therefore, GPT (IIRC), but I believe it's the same. So maybe Apple will help standardize EFT on x86 and x86-64 and GPT will be the norm for all x86 and x86-64 OSes?
Frankly, I'd much prefer the IEEE-standardised OpenFirmware over the Intel-backed EFI. But that's not very on-topic :-) /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Tuesday 06 June 2006 12:27, Rob Sell wrote:
Thanks Carl. Looks like that was the problem, msdos label. had to use parted to repartition and relabel to gpt everything seems kosher now. its too bad 'partitioner' in yast2 doesn't give an option to do this. I hosed my system the first time trying to get by without fully understanding how parted works.
I did have a bit of trouble with grub, had to switch to lilo, grub didn't seem to like the huge disk parameters just kept talking about disk params out of range.
Glad it turned out to be on target. Now we've both learned something! regards, Carl P.S. Thanks for the outline, Bryan! More 'tips' for the 'kit bag.' -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (4)
-
Bryan J. Smith -
Carl Hartung -
Per Jessen -
Rob Sell