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

Fri May 7 17:07:18 EDT 2010

So I googled for tutorials on using hdparm but I think I really need to 
umount the drive to run any really useful tests.
# hdparm /dev/sda
/dev/sda:
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 60788/255/63, sectors = 976562176, start = 0

/dev/sda is really 2 hard drives configured as a RAID1 array.  Its also 
running lvm.  What a mess. So when you think about what happens when you do 
a mysql update and the number of possible problems... Is the mysql cache 
configured properly? Am I using the best field types for the data? The best 
db engine,? What file system should I use(eExt3, xfs, jfs)? Lvm or not? Is 
the disk configured properly (read-ahead, DMA)? What RAID level should I 
use?

Get any one of these things wrong and you're screwed.

----- Original Message ----- 
From: "Jim Kinney" <jim.kinney at gmail.com>
To: "Atlanta Linux Enthusiasts - Yes! We run Linux!" <ale at ale.org>
Sent: Thursday, May 06, 2010 10:39 AM
Subject: Re: [ale] why would it take longer to delete a file than 
tocreateit?

> Look through the hdparm variables and see if your drive(s) are in some
> stupid/slow mode.
>
> On Thu, May 6, 2010 at 11:18 AM, John G. Heim <jheim at math.wisc.edu> wrote:
>
>> Well, I guess the *real* question is why is the system so loaded? I 
>> believe
>> its IO bound, based on my dd test, but I don't know why. Its running 
>> mysql
>> with databases for horde3 and drupal. The slow query log is jammed with
>> slow
>> update messages.  But the DB server has 16 Gb of RAM and the entire size 
>> of
>> the mysql data all together is only 3 Gb.
>>
>> I have to figure something is wrong at the OS level because of the slow 
>> dd
>> thing and because I just don't have that much actual data.  I think mysql
>> ought to be able to handle this load like a breeze.  I don't think mysql 
>> is
>> slowing down the server. I think it's already slow and mysql is slow
>> because
>> disk writes are so slow (for some reason).
>>
>> I think I'm going to move the mysql data to another machine temporarily 
>> and
>> turn off mysql and then run my test. I'll bet it speeds up but I'll bet 
>> it
>> doesn't blaze.
>>
>> ----- Original Message -----
>> From: "Greg Freemyer" <greg.freemyer at gmail.com>
>> To: "Atlanta Linux Enthusiasts - Yes! We run Linux!" <ale at ale.org>
>> Sent: Thursday, May 06, 2010 6:15 AM
>> Subject: Re: [ale] why would it take longer to delete a file than to
>> createit?
>>
>>
>> > Michael,
>> >
>> > My phrasing was poor.  I was trying to say what you said.
>> >
>> > Greg
>> >
>> >
>> > On 5/5/10, Michael Trausch <mike at trausch.us> wrote:
>> >> I don't quite understand that. Would it not be faster to perform such
>> >> actions on an idle system as opposed to a loaded one?
>> >>
>> >>   - mike
>> >>
>> >> --
>> >> Sent from my ADP1 running Android 2.1
>> >>
>> >> On May 5, 2010 6:06 PM, "Greg Freemyer" <greg.freemyer at gmail.com>
>> wrote:
>> >>
>> >> Is that on an idle disk/array?
>> >>
>> >> That would be very slow.
>> >>
>> >> But if its busy serving db queries, its not surprising.
>> >>
>> >>
>> >> On Wed, May 5, 2010 at 4:45 PM, John G. Heim <jheim at math.wisc.edu>
>> wrote:
>> >>> Doh! Caching... I shoul...
>> >> --
>> >> Greg Freemyer
>> >> Head of EDD Tape Extraction and Processing team
>> >> Litigation Triage Solutions Specialist
>> >> http://www.linkedin.com/in/gregfreemyer
>> >> CNN/TruTV Aired Forensic Imaging Demo -
>> >>
>> >>
>> http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/
>> >>
>> >> The Norcross Group
>> >> The Intersection of Evidence & Technology
>> >> http://www.norcrossgroup.com
>> >>
>> >>
>> >> _______________________________________________
>> >> Ale mailing list
>> >> Ale at ale.org
>> >> http://mail.ale.org/ma...
>> >>
>> >
>> > --
>> > Sent from my mobile device
>> >
>> > Greg Freemyer
>> > Head of EDD Tape Extraction and Processing team
>> > Litigation Triage Solutions Specialist
>> > http://www.linkedin.com/in/gregfreemyer
>> > CNN/TruTV Aired Forensic Imaging Demo -
>> >
>> >
>> http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/
>> >
>> > The Norcross Group
>> > The Intersection of Evidence & Technology
>> > http://www.norcrossgroup.com
>> > _______________________________________________
>> > 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
>> >
>> >
>>
>> _______________________________________________
>> 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
>>
>
>
>
> -- 
> -- 
> James P. Kinney III
> Actively in pursuit of Life, Liberty and Happiness
> Doing pretty well on all 3 pursuits
>

--------------------------------------------------------------------------------

> _______________________________________________
> 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
> 