Many thanks to those who replied:
Butch Deal <email@example.com>
Jeff Wasilko <firstname.lastname@example.org>
Roger B.A. Klorese <email@example.com>
Joe Gotobed <jgotobed@LPL.Arizona.EDU>
Glenn Satchell <Glenn.Satchell@Uniq.com.au>
Brad Young <firstname.lastname@example.org>
Michael J. Shon <mshon@sunrock.East.Sun.COM>
Kevin Sheehan <Kevin.Sheehan@uniq.com.au>
Steve Phelps <email@example.com>
Guy Harris <firstname.lastname@example.org>
My original message follows. The response(s) to each question are
handled in turn.
------- Forwarded Message Follows -------
> We have a Sparc 20 with a 30GB (30 x 1GB) SparcArray, and we are
> using the Veritas volume manager which came with the array. I hear
> that Sun will eventually discontinue support for the Veritas product
> in favor of their Online/Solaris DiskSuite offering.
Several responders commented on this item. The gist is that, even if
Sun drops support for Veritas Volume Manager, Veritas will still be
there to support the product. It is not at all clear at this time
whether Sun will in fact drop support for Veritas, we'll just have to
wait and see.
Several responses also contained the sender's preference for
Online/Solaris DiskSuite over Veritas, or vice versa. I guess it
depends largely on what you're used to working with.
> I find this news disturbing because DiskSuite apparently has a file
> size limit of 2 GB. Our largest production file, which grows
> monthly, is presently sized at 1.4 GB. In addition, we have
> customer data files which threaten to blow past the 2 GB limit. My
> questions are as follows:
> 1) Does the Veritas product have the same 2 GB file size limit as
General Consensus: The 2 GB file limit is an OS limitation.
Since the file offset is stored in a signed integer, Sun OS (and,
according to some, most Unix-derived systems) are limited to a 2 GB
file size. I have read articles in some of the Sun/Solaris
newsgroups referring to an C function call named llseek() to access
files larger than 2 GB, but this only helps me if I'm writing all of
my own software. A couple of senders indicated that Sun and/or
various standards bodies are working on eliminating the 2 GB file
system limitation (i.e., integrating/standardizing 64-bit filesystem
support), and that this feature will appear in an upcoming release of
> 2) How painful is the transition from Veritas to DiskSuite?
General Consensus: How good am I at administration?
Regardless of the tools involved, I would have to backup,
reconfigure, and restore the array, which is what I figured I would
have to do anyway. DiskSuite apparently uses a lower-level view of
the disk array than Veritas, which makes DiskSuite more flexible but
perhaps harder to learn for someone who is not experienced with it.
> 3) Does anyone know of a workaround (or, better yet, a fix from Sun)
> for the 2 GB file size limit?
General Consensus: To quote one sender, "Upgrade to Solaris 2.x, for
some value of 'x' greater than 5". See Question 1.
Responses from several senders included "switch to an OS which
supports >2 GB files." Not practical at this time.
> 4) Since we are planning to expand our disk storage anyway, would we
> be better off using the "low-tech" approach and buying a set of 9 GB
> drives with no volume management to handle the really big files? Is
> this practical or even possible?
General Consensus: Nope.
Paraphrased from one sender: "Do you really want to fsck a 9 GB
filesystem after a system crash?"
Other responders pointed out the performance hit I would take from
having a single-spindle, non-striped, non-RAID filesystem which would
still have a 2 GB file size limit.
One responder indicated that he had imposed a mapping library between
the applications and the data which allowed a logical multi-GB file
to be stored as 1 GB physical "chunks". While we may be able to
accomplish this with our database server software, we have not yet
imported the really big files into it since we haven't yet developed
application support calls to access them.
Once again, many thanks to all who responded.
/_/_/ David Bryant
/_/_ Library Systems and Services, Inc.
/_/_/ All standard disclaimers apply.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:55 CDT