[ale] Long lag for command line

[Alex Carver]

IDE not SATA. ;)  And no, running any command twice doesn't speed things 
up.  Swap shouldn't matter in this case because the majority of RAM is 
free and ls and other basic shell commands don't require that much RAM. 
  The problem didn't crop up until recently (maybe four or five days 
ago) but the machine had been running continuously without issue for 
about 50 days (would have been 130 days but a long duration power 
failure took care of that).

I'm thinking it was the NFS that Jim Kinney pointed out even though I 
wasn't working on an NFS mount point, just local disk.  I went ahead and 
just rebooted everything so that I could do some fsck checks and let 
everything clear out.  It's working fine right now after the reboot. 
The NFS mounts have been reestablished so we'll see what happens in a 
few days just in case some kind of delayed NFS error is the cause of the 
weirdness.

On 6/28/2013 21:26, Ron Frazier (ALE) wrote:
> Not to beat the hdd thing to death, but, could there be a bad sata cable
> or something?  Also, does the lag go away once the command is loaded the
> first time?  You could try running the commands from a different hdd or
> an external drive if you have one, or perhaps a memory stick.  Totally
> pulling this one out of thin air, but corrupt swap file?
>
> Sincerely,
>
> Ron
>
>
> On 6/29/2013 12:02 AM, Alex Carver wrote:
>> True, but ls doesn't use tmp files and that hangs up, too.
>>
>> On 6/28/2013 20:59, Pete Hardie wrote:
>>> vi will use temp files, whose location typically is under /tmp.  I've
>>> had
>>> systems with a full disk misbehave in odd ways like that
>
>