Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!mit-eddie!apollo!apollo.hp.com!pcc From: pcc@apollo.HP.COM (Peter Craine) Newsgroups: comp.sys.apollo Subject: Re: SR10.1.p bsd/sysv ls -l hangs for large files Message-ID: <4786940c.20b6d@apollo.HP.COM> Date: 19 Dec 89 21:30:00 GMT References: <611@nikhefh.nikhef.nl> Sender: root@apollo.HP.COM Reply-To: pcc@apollo.HP.COM (Peter Craine) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 33 In article <611@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > If you do a 'ls -l' for a directory containing some very big files, > the command may take very long, or may never finish. It seems to be > dependent on the size of the files. > It is not working for both bsd and sysv. /com/ld -a works ok. > This is not as simple as it sounds. /com/ld shows the total disk space allocated to the file. Simple, right? Well 'ls -l' shows the amount of READABLE data in the file (if you were to do UNIX read() calls). Big difference. So, 'ls' is actually calling the type manager involved to figure out "how large" the files are. (Yes, this is why the sizes will differ between 'ls' and 'ld'. For many file types, this does not pose a problem. However, for 'rec' typed files, each record has to be considered independently. I have seen this type of behaviour from SR10.1 'ls' on rec files. If the problem still exists at SR10.2, it is less noticable at 10.1. > As a side effect, for the duration of such hanging ls, the rgy daemon > becomes unavailable for servicing requests. I have never seen this symptom, but I don't use a node that has rgyd running on it. > My god, what is going on here? Isn't ls just doing a stat() of a file? Yes, stat() is doing the call to the type manager. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP?