I wonder if that would affect me as i am planning on doing 1 raid device at first, (the 4 300GB's) and making a LVM out of it. Then adding another device later with the 4 500's and adding in the new LVM drives into the current group. So i would have >2tb but it would be spread across 2 raid devices and 8 disks. -jason
Quoting Mark Haney mhaney@ercbroadband.org:
Jason Ragsdale wrote:
All, I am looking to build a NSF server starting with: 4 x 300GB drives RAID5, and adding 4 more 500GB RAID5 drives later. Is there a max filesystem size limit with fedora core 4? Or are there any other options that may cause me issues later down the road? Thanks in advance. -Jason
I just found out that fdisk doesn't like raw devices > 2TB. Don't know of a way around that limitation, but that's the only one I can think of.
-- Interdum feror cupidine partium magnarum Europae vincendarum
Mark Haney Sr. Systems Administrator ERC Broadband (828) 350-2415
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Jason Ragsdale wrote:
I wonder if that would affect me as i am planning on doing 1 raid device at first, (the 4 300GB's) and making a LVM out of it. Then adding another device later with the 4 500's and adding in the new LVM drives into the current group. So i would have >2tb but it would be spread across 2 raid devices and 8 disks. -jason
The array I'm building is 7.5TB across 15 500GB SATA2 drives. In communication with the vendor over this, I found out that little tidbit about fdisk. So, I'm going to have to do the same thing with LVM groups. I understand there might be a performance hit on this, but I won't know until I get it built and tested. Does anyone know the deal with FDISK? Are there plans to fix that little problem? I mean pretty soon 2TB is gonna be a drop in the bucket for most filesystems, and considering ext3 handles 64TB or more, this seems a horrible limitation.
Quoting Mark Haney mhaney@ercbroadband.org:
Jason Ragsdale wrote:
All, I am looking to build a NSF server starting with: 4 x 300GB drives RAID5, and adding 4 more 500GB RAID5 drives later. Is there a max filesystem size limit with fedora core 4? Or are there any other options that may cause me issues later down the road? Thanks in advance. -Jason
I just found out that fdisk doesn't like raw devices > 2TB. Don't know of a way around that limitation, but that's the only one I can think of.
-- Interdum feror cupidine partium magnarum Europae vincendarum
Mark Haney Sr. Systems Administrator ERC Broadband (828) 350-2415
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Mark Haney wrote:
Jason Ragsdale wrote:
I wonder if that would affect me as i am planning on doing 1 raid device at first, (the 4 300GB's) and making a LVM out of it. Then adding another device later with the 4 500's and adding in the new LVM drives into the current group. So i would have >2tb but it would be spread across 2 raid devices and 8 disks. -jason
The array I'm building is 7.5TB across 15 500GB SATA2 drives. In communication with the vendor over this, I found out that little tidbit about fdisk. So, I'm going to have to do the same thing with LVM groups. I understand there might be a performance hit on this, but I won't know until I get it built and tested. Does anyone know the deal with FDISK? Are there plans to fix that little problem? I mean pretty soon 2TB is gonna be a drop in the bucket for most filesystems, and considering ext3 handles 64TB or more, this seems a horrible limitation.
You reall need to read up on parted, it has some very nice features (though I find it a little clumsy at the commandline). I copied an 80 Gm HDD to a file and set to, manipulating the partitions in parted. It failed when I tried to move an extended partition, but it's come a long way since last I looked. Andrew is to be commended.
I think there are a couple of GUI wrappers for it too.
Mark Haney wrote:
Does anyone know the deal with FDISK? Are there plans to fix that little problem? I mean pretty soon 2TB is gonna be a drop in the bucket for most filesystems, and considering ext3 handles 64TB or more, this seems a horrible limitation.
Dave Jones referred to it up-thread. For example: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as... says: · The commonly-used MS-DOS partition table format can not be used on devices larger than 2 TB. For devices larger than 2 TB, the GPT partition table format must be used. The parted utility must be used for the creation and management of GPT partitions. To create a GPT partition, use the parted command mklabel gpt.
Don't worry about the "zseries" or the "s390" in the URL: that's just the system that's most likely to hit this issue. It's talking about the same partition table format.
It's not a bug in fdisk: it does exactly what it's supposed to do -- handle MS-DOS style partition tables. It's those tables that can't handle devices larger than 2 TB -- there just isn't enough space in the fields. It's a harder limit than 640K was for real-mode DOS, or 2 GB was for FAT16. Change the partition table format so it can handle larger devices, and *it's not DOS partition table format any more*, and operating systems that don't know about the new format can't use the disk. At all.
And if you're going to go for something other than traditional MS-DOS partitions, you might as well go for something with a reasonable -- er, *any* design, that doesn't have the archaic "4 primary, one of which may be extended, and umpteen logical" limitations. Like GPT.
Note that none of this refers to the format of filesystems within those partitions (ext3, reiser, FAT32, etc). It refers to the way the partitions themselves are defined and stored on disk. The partition table chops up the disk into partitions, and then you put "normal" filesystems in the partitions. [1]
James.
[1] Or not. Swap partitions and raw device access are beyond the scope of this e-mail...
On Sun, 2006-01-01 at 21:26 +0000, James Wilkinson wrote:
It's not a bug in fdisk: it does exactly what it's supposed to do -- handle MS-DOS style partition tables. It's those tables that can't handle devices larger than 2 TB -- there just isn't enough space in the fields. It's a harder limit than 640K was for real-mode DOS, or 2 GB was for FAT16. Change the partition table format so it can handle larger devices, and *it's not DOS partition table format any more*, and operating systems that don't know about the new format can't use the disk. At all.
So would this limit only apply to your boot *disk*? (Disk, not partition.) If you had a separate drive, for the really big one, could your OS use something much larger than the BIOS knew what to do with?
James Wilkinson wrote:
Mark Haney wrote:
Does anyone know the deal with FDISK? Are there plans to fix that little problem? I mean pretty soon 2TB is gonna be a drop in the bucket for most filesystems, and considering ext3 handles 64TB or more, this seems a horrible limitation.
Dave Jones referred to it up-thread. For example: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as... says: · The commonly-used MS-DOS partition table format can not be used on devices larger than 2 TB. For devices larger than 2 TB, the GPT partition table format must be used. The parted utility must be used for the creation and management of GPT partitions. To create a GPT partition, use the parted command mklabel gpt.
Don't worry about the "zseries" or the "s390" in the URL: that's just the system that's most likely to hit this issue. It's talking about the same partition table format.
It's not a bug in fdisk: it does exactly what it's supposed to do -- handle MS-DOS style partition tables. It's those tables that can't handle devices larger than 2 TB -- there just isn't enough space in the fields. It's a harder limit than 640K was for real-mode DOS, or 2 GB was for FAT16. Change the partition table format so it can handle larger devices, and *it's not DOS partition table format any more*, and operating systems that don't know about the new format can't use the disk. At all.
I don't agree. It is certainly very similar to the differences between FAT12 and FAT16. A FAT16 FAT is definitely not FAT12 at all. But that doesn't mean that FAT16 is a whole 'nother ball of wax.
And if you're going to go for something other than traditional MS-DOS partitions, you might as well go for something with a reasonable -- er, *any* design, that doesn't have the archaic "4 primary, one of which may be extended, and umpteen logical" limitations. Like GPT.
I'm not familiar with GPT. However, to use larger discs, something must certainly be done. It also certainly makes sense that, if the old format cannot be "jiggered" up, one reconsider the circumstance from scratch.
Note that none of this refers to the format of filesystems within those partitions (ext3, reiser, FAT32, etc). It refers to the way the partitions themselves are defined and stored on disk. The partition table chops up the disk into partitions, and then you put "normal" filesystems in the partitions. [1]
Well, mostly, if the first sector on the disc ends in AA55 the BIOS will almost certainly load it, and one can put any boot manager on there one wants.
James.
[1] Or not. Swap partitions and raw device access are beyond the scope of this e-mail...
I'm not sure that swap partitions make sense any more. I've seen data that indicates that, at least with ext3, using a swap file is no slower than using a partition.
Mike
-
James Wilkinson -
Jason Ragsdale -
John Summerfield -
Mark Haney -
Mike McCarty -
Tim