Aventures in storage land - damned if you do, damned if you don’t…
So if you remember my attempt to install Solaris 10 a little while back, I ended up running into a little problem. Namely, I had a couple of Apple-sourced LSI FC HBAs I wanted to connect up to the pair of Apple XServe RAID shelves. The problem was that while LSI provides a lovely “itmpt” driver for use in Solaris 10 x86, so does Sun.. Sort of.. You see, the Sun v20z and galaxy servers all use LSI “MPT Fusion” onboard SCSI/SAS controllers. So Sun wisely provides a stock “mpt” driver in Solaris 10 that speaks to the onboard adapters just fine. But Sun’s driver does not support fibre-channel HBAs! So you have a stock driver that can’t talk to the FC HBAs, and a 3rd party driver LSI driver that can speak to the FC HBAs and the onboard, but can’t be installed since there’s already an ipt driver bound to the onboard device… Apparently there is a workaround, but Sun tech support and #opensolaris strongly discouraged it. They recommended just buying QLogic HBAs. Too late for that.. *sigh*
But Red Hat Enterprise Linux 4 just boots up and sees the works no problemo! Great! Everything was going good, I added the 4 2.73TB LUNs into a volume group with LVM2 and everything was just grand until this:
[root@ensembl01 ~]# mkfs.ext3 -T largefile4 /dev/xserve/datalv mke2fs 1.35 (28-Feb-2004) mkfs.ext3: Filesystem too large. No more than 2**31-1 blocks (8TB using a blocksize of 4k) are currently supported.
8TB for a maximum filesystem size?!? In 2006?! Gah!
Damnit. Screwed on RHEL too. I’m still shocked that Red Hat only includes EXT2/3 in their Enterprise product.. Why the hell isn’t XFS in there?
I really, really wanted a single 11TB filesystem to keep things simple for the developers of the app that’s going to use this storage. There’s nothing worse than already being on a suboptimal path and realizing that you’re going to have to compromise even more…
9 Comments
Jump to comment form | comments rss [?] | trackback uri [?]