SCIENTIFIC-LINUX-USERS Archives

December 2005

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Fri, 2 Dec 2005 11:29:02 -0600
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (108 lines)
Thanks to those who have responded.  A short summary:

(1) fdisk cannot make large partitions, limit is 1TB.  But, the SL4.1 
release notes (which Steve Yellin quoted) explains how to get around this 
problem, namely using the parted utility and labeling the disk 'gpt'.  I 
can then create a single partition of 5.6TB which is the size of the raid 
set on my disk array.  I never got around to cobbling smaller partitions
into a large one via LVM.  This parted procedure is simpler.

(2) The release notes claim an 8TB limit for ext3 filesystems.  Although I 
have a 5.6TB on my array's partition table, mke2fs cannot make anything 
more than 1TB.  I use the generic 'mke2fs -j -L /bigdisk /dev/sda1'.  Are
there special command options to make it go over 1TB?

(3) Regardless of whether ext3 has a 1TB or 8TB limit, Ichihara's comments
jogged my memory about cpu utilization.  I have read the large ext3
filesystems hog the cpu.  This was from a posting about the merits of JFS
which apparently does not hog the cpu. And according to Ichihara, neither
does XFS.  

I'm going to rebuild the kernel to enable XFS and JFS since ext3 is excluded
because of (3).  Please continue to post any thoughts and remarks you may
have.

Ken



---------- Forwarded message ----------
Date: Thu, 1 Dec 2005 15:22:57 -0800 (PST)
From: Steven J. Yellin <[log in to unmask]>
To: Troy Dawson <[log in to unmask]>
Cc: Ken Teh <[log in to unmask]>, [log in to unmask]
Subject: Re: ext3, xfs, jfs on large partitions

ftp://linux.fnal.gov/linux/lts4x/i386/SL.documentation/RELEASE-NOTES-U1-x86-en
says about SL4.1:

"
   The ext2 and ext3 filesystems have an internal limit of 8 TB.  Devices
   up to this limit have been tested.
"

   Whoever tested a device up to the limit of 8 TB might have been able to
make a partition that big.  But one may also put a file system on an
unpartitioned disk.
   There's a limit on the size of md software raid for individual members:

"
   The maximum size disk that can be a member of an md software RAID
   set is 2 TB. The md RAID device itself can be larger than 2 TB.
   Devices have been tested up to 8 TB.
"




Steven Yellin

On Thu, 1 Dec 2005, Troy Dawson wrote:

> Ken Teh wrote:
> > I've just installed SL4.1 on a dual opteron 6.4TB disk array system. This is
> > my first disk array, so I'm full of questions.  The disk array is configured
> > as one large disk partition.  At 5.6TB, it's larger (according to what I've
> > read) than what ext3 can handle.  So, I'm thinking of putting either JFS or
> > XFS on the system.
> >
> > SL4.1's stock kernel does not have built-in JFS nor XFS support.  But there
> > is a contributed XFS rpm.  Is this the preferred filesystem for large
> > partitions?  If so, why?
> >
> > I don't know the history of XFS, but I first encountered JFS in the late 80s
> > when I worked on an AIX machine.  Also, I read on the web that JFS has
> > better performance than XFS.
> >
> > Comments??
> >
> > Ken
>
>  From the Scientific Linux 4.2 release notes
>
>       o The current ext3 file system limit in Scientific Linux 4.2
>         is 8 terabytes. The e2fsprogs package has been updated to
>         adhere to this file system limit.
>
> So it looks like if you use S.L. 4.2 you should be ok with 4.2.
> (OK, so we haven't *officially* released it ... there is one file
> driving us nuts, but what's in 4.2 is really what's going to be released.)
>
> But the question about the other stuff I think would be good to be
> answered.  But I'm not really the expert.
>
> This is what I've been told.
>
> XFS - good for very large files
> Reiser - good for lots of small files
>
> Well ... that's not very much information, but all I have at the moment.
>
> Troy
> --
> __________________________________________________
> Troy Dawson  [log in to unmask]  (630)840-6468
> Fermilab  ComputingDivision/CSS  CSI Group
> __________________________________________________
>

ATOM RSS1 RSS2