fred@mot.UUCP (Fred Christiansen) (12/07/84)
[]
A few references are creeping across the net re paging in the new release.
Righto, and also advisory record and file locking, plus MilStd Fortran77.
An interesting observation on the new max file size of 16 Mbytes
probably due to the 24 bit addresses in the 3B series. Also matches the
addressability of the 68000 (and successors), 32016 (and sucessors),
and, I believe, the 286. Don't know about z8000 or z80,000.
Question: why not more fanfare from AT&T? Why the indirect
"announcement"?guy@rlgvax.UUCP (Guy Harris) (12/08/84)
> A few references are creeping across the net re paging in the new release. > Righto, and also advisory record and file locking, plus MilStd Fortran77. Well, it's *about time*... > An interesting observation on the new max file size of 16 Mbytes Well, given a 512-byte file system, 10 direct blocks, one singly-indirect block, one doubly-indirect block, and one triply-indirect block, I get about 1 Gbyte as the maximum file size. Oh, do you mean a new file size *ulimit* of 16 Mbytes? Feh. Anybody know the home address of the person who invented "ulimit", so we can all firebomb his/her home? In both System III and System V, the file size ulimit *for process 0!* is set *in the kernel*, and is set from a *hard-wired constant* to boot! Why the initial value for this limit should not be infinite, why it should be set in the kernel rather than settable by something nice like "init" or "login", and why it should be hidden in the source code rather than out in the open in an include file escapes me entirely. The only explanation I can think of is homesickness for PWB/UNIX (S3 and S5 are derived from a mix of V7, PWB/UNIX, and various other internal UNIX systems), where the V6 file system was hacked to only support singly-indirect blocks and as such didn't support files bigger than 1 Mbyte in any form. Gak. Well, we recently raised the limits on the System III systems we sell; and in our 4.2/S5R2 system the initial limit will be at a very reasonable value - namely, RLIM_INFINITY. 'Nuff said. > probably due to the 24 bit addresses in the 3B series. Also matches the > addressability of the 68000 (and successors), 32016 (and sucessors), > and, I believe, the 286. Don't know about z8000 or z80,000. Alas, according to my copy of the BSTJ issue on the 3B20D, it does, indeed, have 24-bit virtual addresses (unlike a certain competitor from a certain second-largest computer company which supports 31-bit virtual addresses and on whose machines System V *will* run). I hope they didn't make the same mistake with the WE32000's MMU chip, or with the 3B5 MMU. Also, the 68012 is a successor to the 68000 but supports addresses longer than 24 bits, the 32016 (according to my data book) supports 24-bit addresses but I'd be disappointed if the 32032 didn't support longer ones, the Z8000 does support 24-bit addresssing but not really 24-bit linear addressing, the Z80,000 almost certainly supports linear address spaces larger than 2^24, and the 286 doesn't support big linear address spaces, period. Heck, even IBM learned that 24 bits can be limiting, and probably spent umpteen million dollars making the 360's successors support 31-bit addressing (of course, they were screwed by advertising that you could stuff type codes into the upper 8 bits of pointers and by stuffing type codes there themselves). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/08/84)
> > An interesting observation on the new max file size of 16 Mbytes I think "process size" was intended.. > I hope they didn't make the same mistake > with the WE32000's MMU chip, or with the 3B5 MMU. The WE-32001 directly addresses 2^32 bytes (4 gigabytes).