kim@uts.amdahl.com (Kim DeVaughn) (07/22/90)
I've had a report from Christopher Wichura on a strange problem that has shown up when using the new version of "ls" that was recently posted (v4.0k) under 2.0 on a 3000 (Kickstart 36.141 and Workbench 36.68). I'm at a loss to figure out what the problem is, so ... Chritopher writes (in several email msgs, my words be prefixed with ">>"): > A couple of notes, though: You mentioned you fixed some bugs and I was > hoping this would fix a problem I have with v3.1 on mt 3000: If I do an ls > on certain assigned directories (not all of them, just a couple do this) > the system crawls like it was running at half a megahertz and every command > issued after that, whether in the same shell or not, also crawls. The only > way to restore the system to normal is to three finger salute it. > > Commodore's `dir' and `list' commands work, however, and I am forced to use > > > A couple of days ago I sent you some mail abot ls v4.0k and how it doesn't > work on the 3000 (at least it is not stable). I have since talked to some > other people and they said they had the same problems, both with 3.1 and > now 4.0k. > > PS: If I boot the machine and enter `ls uuspool:' right away, the system > gets trashed. However, if I do a directory on uuspool: first, using `dir' > or `list', and then do the ls on it, the program works fine... > >> Sounds like Dir and List are initializing something new under 2.0, which >> lends some (speculative) weight to my hunch above. [ that the problem is >> due to new 2.0 calls/features/etc ] >> >> Just to clarify ... when you say "gets trashed", you mean the system slows >> *way* down, right (i.e., not a Guru or Task Held)? Is that the entire >> system (any process), or just subsequent "ls'ing", "Dir'ing", etc? Also, >> since you said earlier that this only happens with *some* assign's, is >> there anything "special" about the ones that it does happen with (like >> being assign'd to a devices root node (or not), etc? > > Yes, that is what I mean. Anything run from a CLI after that (or which > causes disk access) also crawls as well. > > I have not been able to determine anything special about any of the assigns. > Some are to directories in the root of a partition, some are to directories > several levels deep. > > I mailed Dave Haynie at first as I was wondering if it was a problem with > using BindNames to do all my assigns for me. He said that he had the same > problem on his system with ls 3.1 and had determined that BindNames was > __NOT__ the cause of it (he is using the ls from Manx now he says). For awhile, it seemed that the culprit might be calls to Info(), but that turned out not to be the case. A clue may lie in Randell's recent posting WRT ExAll(): > >I guess what I meant was `is ExAll() atomic at the fs level, as well and > >do the OFS and FFS take advantage of that?'? > > In fact, we managed this for ExNext as well. This is why it slows > down a lot if you UnLock() and re-Lock() on every ExNext (like the Manx > scdir and lattice dnext) - it has to rebuild the table, which may mean > scanning until it finds the same entry again. However, it's a BIG win under > normal operation. However that does NOT seem to explain why this problem would show up only on (some) assign'd dirs, and would not show up on them at all if the CBM List or Dir cmds were run first. Nor does it seem to explain why "anything run from a CLI, or that makes a disk access" also "crawls", once this condition has manifested itself. And, no, "ls" does not use the Lattice "dnext". This seems to be a new "class" of bug, as I haven't heard or seen anything like it before on the Amiga. What's going on here? And what (if anything) is a reasonable workaround that will work for both 2.0 and 1.3? Randell ...? /kim P.S. Yes, a copy of this has been sent to bugs@cbmvax.commodore.com. -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25