daemon@rutgers.UUCP (03/31/87)
From: "John G. Ata" <Ata@RADC-MULTICS.ARPA>
There is a problem with the RAM: device where if one creates
an empty file and then deletes it, the block count decrements by one
over the original causing it to go negative. This can be reproduced by
typing:
copy * ram:test
^\
delete ram:test
At this point the ram: block count is incorrect and a info command will
either verify this or guru with a "divide by zero" fault.
This seems like a serious deficiency, and probably should be
reported, so am taking a shot.
Thanks,
John G. Ata
---(82)---hadeishi@husc7.UUCP (03/31/87)
Re: 1.2 RAM: device . . . The RAM: device under 1.2 has several problems, although not quite as bad as under 1.1. Sometimes renaming files under the RAM: device doesn't work correctly. The absolute WORST problem, though, with the RAM: device (not even a device, really, just an AmigaDOS Handler), is that it allocates memory with AllocMem() and thus totally fragments memory that should be reserved for code and data. The problem with this is that if you are using RAM: heavily (for program development, for example), and thus are writing and deleting small files all the time, you end up with a free list that looks like Swiss Cheese. Then, try to edit a document! With any editor, you end up with you text in a clist which is fragmented all over memory, so it takes an infinite amount of time just to do a simple search through a relatively large document (sometimes crashing the machine). I found the performance of my programs, compilers, and editors improved 500% when I started using Perry's vd0: recoverable RAMdisk device which does the Right Thing and allocates memory starting from the TOP of RAM rather than using AllocMem() and allocating from the BOTTOM. -Mitsu P.S. BTW, Perry, sorry I haven't sent in the $10 yet, but with midterms and all, well, excuses, excuses. Okay, I'm writing the check NOW. Okay, okay, my conscience is finally assuaged! AAaaaaaah!!!!!!!!