Hello, I have: CentOS4.1 x86_64 directly-attached Infortrend 9TB array QLogic HBA seen as sdb GPT label created in parted I want one single 9TB ext3 partition. I am experiencing crazy behavior from mke2fs / mkfs.ext3 (tried both). If I create partitions in parted up to approx 4,100,000 MB in parted, mkfs.ext3 works great. It lists the right number of blocks and creates a filesystem that fills the partition. Any partition approx 4,200,000 MB and larger, mkfs.ext3 sees a totally random number of blocks, equivalent to a few hundred GBs of space. It create healthy partitions, but they are way too small!!!>From dmesg to parted, I can see the system recognizes the hardwareproperly, including the number of blocks. And I know the upper limit of ext3 is 16TB, not 4! What am I doing wrong? What wall am I hitting around 4TB? HELP!!! Thanks, Francois Caen output of a few commands: (parted) p Disk geometry for /dev/sdb: 0.000-9149550.000 megabytes Disk label type: gpt Minor Start End Filesystem Name Flags 1 0.017 4100000.000 ext3 <------ 4TB partition 2 4100000.000 9149549.983 <------- 5TB partition # mke2fs -n /dev/sdb1 mke2fs 1.35 (28-Feb-2004) Filesystem labelOS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 524812288 inodes, 1049599995 blocks <------------ GOOD!!!! 9530326 blocks (0.91%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 32032 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544 # mke2fs -n /dev/sdb2 mke2fs 1.35 (28-Feb-2004) Filesystem labelOS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 109477888 inodes, 218942971 blocks <-------- BAD!!!!! only 830GB!!! 10947148 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 6682 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848
On Sat, 2005-09-10 at 19:03 -0700, Francois Caen wrote:> What am I doing wrong? What wall am I hitting around 4TB?There are some size limitations _below_ the current 16TiB (17.6TB) "absolute" limitations depending on various geometry/hardware considerations. Kernel version can also reduce the "absolute" as well. I don't have a list because I personally never make an Ext3 filesystem greater than 1TB, period. And I try to keep them below 100GBs if I can help it. As I mentioned before, I have some Fedora Core 3 (FC3) systems in test/limited production with XFS, which is what I use for TB-sized filesystems. So far, so good, at least on the very latest kernels. But I have not deployed XFS in heavy production since the 1.3.1 release on Red Hat Linux (RHL) 9, and the overwhelming majority of my deployments were the 1.2.x release on Red Hat Linux (RHL) 7.3. -- Bryan J. Smith b.j.smith at ieee.org http://thebs413.blogspot.com ---------------------------------------------------------------------- The best things in life are NOT free - which is why life is easiest if you save all the bills until you can share them with the perfect woman
Add to your soap-box: the standard 'man' is disregarded, you are left to use (non-standard) info. There's a man -k call, I haven't found an info -k equivalent. Yes, there's a great calling for thankless man page writing in the *nix world. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> wam at HiWAAY.net 09/13/05 08:24AM >>>Chris Mauritz wrote: <snip>> > Perhaps I'm just extremely lucky, but I've not run into this magic 1TB > barrier that I see bandied about here. Heck, if you're willing to > roll the dice on Hitachi drives, you can get a terabyte these days > with just 2 hard disks in the array with RAID0 or 3 disks with RAID5. > Unfortunately, a lot of the documentation and FAQs are quite out of > date which can lead to some confusion.Grrrrrrrrrrr, 1 of my *long time* complaints w/ Linux (any Linux, apparently) is that nobody bothers to keep man-pages/FAQS/other-documentation up to date. The cron(8) on my SuSE 9.2 P4 is dated 1996 (!!!). I lay this at the feet of the distro folks myself, but none of them have taken it up :-) .... -- William A. Mahaffey III --------------------------------------------------------------------- Remember, ignorance is bliss, but willful ignorance is LIBERALISM !!!! _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
Agreed: If ANYBODY knows an info-to-man method please post. Second-runner-up: info-to-html would work (html is what info tries to emulate in text-only mode...) Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> wam at HiWAAY.net 09/13/05 10:35AM >>>Brian T. Brunner wrote:>Add to your soap-box: the standard 'man' is disregarded, you are left to use (non-standard) info.I have tried to find tools to convert info pages to man, but no luck. I *think* there are tex-to-man tools, but the tex data (from which info documents normally come) isn't always installed .... The combination of man & less is about the best text-based info system I could dream up. Oh well .... -- William A. Mahaffey III --------------------------------------------------------------------- Remember, ignorance is bliss, but willful ignorance is LIBERALISM !!!! ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated