× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We're experiencing a strange disk performance problem with large (> 1
GB) files stored on the root IFS file system.
When we delete one of such files, we see that:
1) from WRKDSKSTS, all disks are 95%-100% busy until the delete
operation is completed; and obviously during this period of time the
whole system becomes unresponsive
2) file deletions become slower (in terms of MB/s) as the file size increases!

take a look at the table below: for this test, temporary IFS files
were created in /tmp with the QSH command
dd if=/dev/zero of=/tmp/dummy bs=1024 count=1048576 (2097152..) , then
deleted with rm /tmp/dummy

MB dd s dd MB/s rm s rm MB/s
1024 15.4 66.5 4.8 213.3
2048 26.4 77.6 16.6 123.4
4096 64 64.0 99 41.4
8192 107 76.6 306 26.8

first column: file size in megabytes
second column: time elapsed to create the file in seconds
third column: file creation speed (column 1 / column 2, MB/s)
fourth column: time elapsed to delete the file in seconds
fifth column: file deletion speed (column 1 / column 4, MB/s)

So it took over 5 minutes to delete the 8 GB file (while the whole
system was almost unusable..)
Given that deletion speed seems to decrease quickly with file size,
does this mean that it will take almost forever for a, say, 20 GB
file? It makes no sense.

Some background information (please note that this a Bladecenter with
1xVIOS-based power blade and virtualized storage)
IBM Power PS700 on a Bladecenter S, OS 6.1.1
SAS Raid controller, 8x559 GB 15,000 rpm SAS disks
7x95443 MB LUNs (tot. 668 GB) in ASP1, 66% used

So can this be considered "normal"? Something wrong with our hw/sw
storage configuration? Any suggestion?

tnx

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.