[ale] why would it take longer to delete a file than tocreateit?

[Lightner, Jeff]

Also it is a common practice of some vendors to disable write cache when
replacing some components just to avoid the possibility of failure even
when the part is hot swappable and redundant.   There's been a couple of
times we've seen vendors forget to re-enable it after the replacement.

 

________________________________

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Greg
Clifton
Sent: Thursday, May 06, 2010 1:50 PM
To: Atlanta Linux Enthusiasts - Yes! We run Linux!
Subject: Re: [ale] why would it take longer to delete a file than
tocreateit?

 

Speaking of RAID arrays, one thing that can compromise performance is
having write caching turned off, which, it is my understanding, should
be done for safety of the data if the RAID controller is not equipped
with it's own battery backup.

GC

On Thu, May 6, 2010 at 1:22 PM, JK <jknapka at kneuro.net> wrote:

On 5/6/2010 9:39 AM, Jim Kinney wrote:
> Look through the hdparm variables and see if your drive(s) are in some
> stupid/slow mode.



Begging the question: what counts as "stupid/slow"?  I know that having
DMA turned off, or set wrong, will kill performance.  What else should
be checked?

And Google leads me to:

http://www.linuxclues.com/articles/20.htm

In general, PIO modes are slowest and UDMA modes are fastest, correct?
I remember a while back I had a 160G RAID array that was literally
taking days to rebuild. Turned out the HDs were in like PIO3 or
something.
Changed to UDMA4 and the rebuild completed in fifteen minutes.

-- JK


--
Forget Jesus: stars died so that you could be here today.
 - physicist Lawrence Krauss

_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
 
Proud partner. Susan G. Komen for the Cure.
 
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100506/4110f595/attachment.html