List Info

Thread: large filesystem tuning suggestions




large filesystem tuning suggestions
user name
2006-11-30 04:26:02
hello all we are configuring rhel es 4 servers with five
apple xserve
raid servers connected to qlogic fibre switch. so far i have
successfully configured 6TB arrays and make them accessible
to rhel
server using advice in rhn-users list archives '[rhn-users]
RHEL 4 -
how can I create a file system over 2 TB' and in
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-M
anual/sysadmin-guide/ch-disk-storage.html#S1-DISK-STORAGE-PA
RTED
  for example............

# parted -i /dev/sda
(parted) mklabel gpt
(parted) mkpart primary ext3 0 6000000
(parted) quit

# /sbin/mkfs.ext3 -j -m 0 /dev/sda1
# e2label /dev/sda1 /prodspace1
# mount /dev/sda1 /prodspace1

-m 0 seems like good option to use to conserve space unless
it is
necessary, pls any suggestions?
linux server and xserve raids are in lab of os x machines to
use for
video production. file served by httpd 2.0 from linux server
on xserve
raids will between 10 mb to 50 mb each.

pls share suggestions + hints for creating and tuning large
filesystems like this in rhel es 4. TIA

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list
large filesystem tuning suggestions
user name
2006-11-30 14:00:30
On Wed, 29 Nov 2006 at 11:26pm, Joseph Cheng wrote

> hello all we are configuring rhel es 4 servers with
five apple xserve
> raid servers connected to qlogic fibre switch. so far i
have
> successfully configured 6TB arrays and make them
accessible to rhel
> server using advice in rhn-users list archives
'[rhn-users] RHEL 4 -
> how can I create a file system over 2 TB' and in
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-M
anual/sysadmin-guide/ch-disk-storage.html#S1-DISK-STORAGE-PA
RTED
> for example............
>
> # parted -i /dev/sda
> (parted) mklabel gpt
> (parted) mkpart primary ext3 0 6000000
> (parted) quit
>
> # /sbin/mkfs.ext3 -j -m 0 /dev/sda1
> # e2label /dev/sda1 /prodspace1
> # mount /dev/sda1 /prodspace1
>
> -m 0 seems like good option to use to conserve space
unless it is
> necessary, pls any suggestions?

You want to give mkfs.ext3 the '-O dir_index' option to turn
on hashed 
b-trees to speed lookups.  Anaconda uses this flag in FSs it
creates, but 
it's not yet a default in mke2fs.  You also probably want to
'tune2fs -i0 
-c0 /dev/sda1' to make sure it doesn't go thorugh a whole
fsck every N 
mounts or M days.

You could also play with the stride option to mke2fs and see
if that helps 
performance.  If you're doing that, you may want to forego
the partition 
and just format the raw disk.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list
large filesystem tuning suggestions
user name
2006-11-30 15:08:41
>> hello all we are configuring rhel es 4 servers with
five apple xserve
>> raid servers connected to qlogic fibre switch. so
far i have
>> successfully configured 6TB arrays ...

>> (parted) mkpart primary ext3 0 6000000

>> # /sbin/mkfs.ext3 -j -m 0 /dev/sda1


> You want to give mkfs.ext3 the '-O dir_index' option to
turn on hashed
> b-trees to speed lookups.  Anaconda uses this flag in
FSs it creates,
> but it's not yet a default in mke2fs.  You also
probably want to
> 'tune2fs -i0 -c0 /dev/sda1' to make sure it doesn't go
thorugh a whole
> fsck every N mounts or M days.


If most of the files are >=10MB then 6TB holds at most
600,000 of them,
which might seem like a lot but is not _that_ many.  So the
mke2fs default
allocation probably gives you hundreds of times more inodes
than you need.
Check with "tune2fs -l"; change with the -N or -i
options to mke2fs.
Once the number of inodes is reasonable (say, at most a few
times the
expected number of files) then fsck won't take so long.

-- 

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list
large filesystem tuning suggestions
user name
2006-11-30 15:08:41
thx i will try both options today.....is there any bad
reactions with
reliability if using hashed b-trees on ext3 fs?

On 11/30/06, Joshua Baker-LePain <jlb17duke.edu> wrote:
> You want to give mkfs.ext3 the '-O dir_index' option to
turn on hashed
> b-trees to speed lookups.  Anaconda uses this flag in
FSs it creates, but
> it's not yet a default in mke2fs.  You also probably
want to 'tune2fs -i0
> -c0 /dev/sda1' to make sure it doesn't go thorugh a
whole fsck every N
> mounts or M days.

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list
large filesystem tuning suggestions
user name
2006-11-30 15:13:06
On Thu, 30 Nov 2006 at 10:08am, Joseph Cheng wrote

> thx i will try both options today.....is there any bad
reactions with
> reliability if using hashed b-trees on ext3 fs?

If there were, I doubt RH would have made it the default in 
anaconda-created FSs.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

--
nahant-list mailing list
nahant-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/nahant-list
[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )