manes@dasys1.UUCP (Steve Manes) (09/26/87)
Does anyone/any group keep a library of Microport kernal patch addresses? What I'm looking for specifically is the patch address(es) for CDLIMIT, which limits the maximum write address. Currently, it's set at 2400 blocks (1,228,800 bytes), which is way too small a filesize max for an application I'm working on (Magpie/UNIX BBS). In fact, I was hoping to pop the cork on the champagne bottle (well, twist the cap on the Chateau Bayonne) and go on-line for Magpie beta tonight until I ran into Microport's brick wall filesize limit whilst porting my TEXT file from the current MS-DOS Magpie (which is well over 5 megabytes). Anyone got a clue? +---------------------------------------------------------------------------+ | Steve Manes (NYC) Roxy Recorders, Inc. (audio) | | UUCP: !{ihnp4|uunet}!{pur-ee|iuvax}!bsu-cs!zoo-hq!magpie!manes | | Magpie BBS Development (UNIX/MSDOS): 212-420-0527 | +---------------------------------------------------------------------------+
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/27/87)
In article <1408@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes: >What I'm looking for specifically is the patch address(es) for CDLIMIT, >which limits the maximum write address. Currently, it's set at 2400 blocks >(1,228,800 bytes), which is way too small a filesize max for an application ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely stupid! Make the initial ulimit "infinite" (it can always be lowered by any user, typically in /etc/profile if the system administrator so chooses, but only a superuser can raise it).
wietse@eurifb.UUCP (Wietse Venema) (09/28/87)
In article <1408@dasys1.UUCP>, manes@dasys1.UUCP (Steve Manes) writes: > Does anyone/any group keep a library of Microport kernal patch addresses? > What I'm looking for specifically is the patch address(es) for CDLIMIT, > which limits the maximum write address. Currently, it's set at 2400 blocks What Microport version do you have? V2.2 has an ulpatch command to patch a new ulimit (up to 16Mb files) into the kernel. Wietse Venema (uucp: mcvax!eutwc1!wietse) (bitnet: wswietse@heithe5)
rickers@drexel.UUCP (Rick Wargo) (09/28/87)
In article <6475@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <1408@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes: > >What I'm looking for specifically is the patch address(es) for CDLIMIT, > >which limits the maximum write address. Currently, it's set at 2400 blocks > >(1,228,800 bytes), which is way too small a filesize max for an application > > ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely > stupid! Make the initial ulimit "infinite" (it can always be lowered by > any user, typically in /etc/profile if the system administrator so chooses, > but only a superuser can raise it). According to the Microport release notes, you cannot have an "infinite" ulimit. The maximum is about 16 Meg (~ 32000 blocks) I have yet to try raising it above what they say is the max. Who knows what can happen? Rickers be. by tion: HURE
steve@nuchat.UUCP (Steve Nuchia) (09/30/87)
In article <1408@dasys1.UUCP>, manes@dasys1.UUCP (Steve Manes) writes: > Does anyone/any group keep a library of Microport kernal patch addresses? > What I'm looking for specifically is the patch address(es) for CDLIMIT, > which limits the maximum write address. Currently, it's set at 2400 blocks > (1,228,800 bytes), which is way too small a filesize max for an application Hmm, I don't know about anyone keeping them, but in the 2.2 release notes, which I have a copy of, says: In order to patch the system-wide ulimit value, use the following syntax: "patch /system5 ulpatch nnn" where nnn is the new ulimit value in decimal. The ulimit value controls the maximum writable file size. The maximum value for the system-wide variable is about 32K blocks, resulting in a maximum file size of about 16MB. The units are 512-byte blocks, so the default of 2400 is exactly big enough to copy a 1.2M floppy. The value in the kernel is the value inherited by init, which then passes it along to all its progeny. -- Steve Nuchia Of course I'm respectable! I'm old! {soma,academ}!uhnix1 Politicians, ugly buildings, and whores !nuchat!steve all get respectable if they last long enough. (713) 334 6720 - John Huston, Chinatown
wietse@eurifb.UUCP (09/30/87)
In article <520@drexel.UUCP>, rickers@drexel.UUCP (Rick Wargo) writes: > According to the Microport release notes, you cannot have an "infinite" > ulimit. The maximum is about 16 Meg (~ 32000 blocks) > I have yet to try raising it above what they say is the max. Who knows > what can happen? > Rickers > ..!drexel!rickers Don't do it or you must boot from the floppy and load a new kernel. At least, that is our experience with release 2.2. Wietse Venema (uucp: mcvax!eutwc1!wietse) (bitnet: wswietse@heithe5)
gwyn@brl-smoke.UUCP (09/30/87)
In article <520@drexel.UUCP> rickers@drexel.UUCP (Rick Wargo) writes: >The maximum is about 16 Meg (~ 32000 blocks) That's why I put "infinite" in quotes. It's easy to see what the real Microport implementation constraint is (number of bits used to hold a block number), but one would think it would be 16 bits (64K blocks) rather than 15.
davidsen@steinmetz.UUCP (10/01/87)
In article <6475@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely |stupid! Make the initial ulimit "infinite" (it can always be lowered by |any user, typically in /etc/profile if the system administrator so chooses, |but only a superuser can raise it). I hope no one is listening... as far as I can tell /etc/profile is not used in any way except by user logins via /bin/sh. One of the biggest problems this might cause is alternate shells, such as uucico. I realize that the hobbiest with 300 baud uucp is not going to get burned, but commercial and business users, with 9600 baud connections, will be unable to easily restrict the uploaded file size. I agree that there should be a simple **well documented** way to change this. As for the original problem, can't superuser set the ligit up as well as down? I'm not root on this system and can't try. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
ballou@brahms.Berkeley.EDU (Kenneth R. Ballou) (10/02/87)
In article <216@eurifb.UUCP> wietse@eurifb.UUCP (Wietse Venema) writes: >In article <520@drexel.UUCP>, rickers@drexel.UUCP (Rick Wargo) writes: >> According to the Microport release notes, you cannot have an "infinite" >> ulimit. The maximum is about 16 Meg (~ 32000 blocks) >> I have yet to try raising it above what they say is the max. Who knows >> what can happen? >Don't do it or you must boot from the floppy and load a new kernel. >At least, that is our experience with release 2.2. Yes, this makes perfect sense. Most likely the type of the variable is "int," so the maximum value is 32767. Kenneth R. Ballou ARPA: ballou@brahms.berkeley.edu Department of Mathematics UUCP: ...!ucbvax!brahms!ballou University of California Berkeley, California 94720
mjy@sdti.UUCP (10/02/87)
In article <216@eurifb.UUCP> wietse@eurifb.UUCP (Wietse Venema) writes: >>[discussion about setting ulimit on Microport 2.2. deleted] >Don't do it or you must boot from the floppy and load a new kernel. >At least, that is our experience with release 2.2. I set my ulimit to 30000 on releases 2.2 and 2.2.2 with no problems. I've never tried to set it to 32767 or 32768 (it was easier to type a bunch of zero's :-), but it's large enough for my purposes. -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel : +1 617 443 5779
tel@Ahab.UUCP (10/02/87)
In article <7501@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: > > I agree that there should be a simple **well documented** way to change > this. As for the original problem, can't superuser set the ligit up as > well as down? I'm not root on this system and can't try. There are a couple of ways to do this. One way affects all terminals and logins: **** CAUTION: keep at least two terminals logged in as root (super user) when following these instructions. In the event that step 4 would fail it is then possible to move /bin/login2 back to /bin/login **** To install ulimit fix perform the following steps: 1) Login in as root 2) Modify the ulimit.c program, replacing the "****" characters on line 11 with the desired ulimit value. (should be a multiple of 2048) 3) execute: mv /bin/login /bin/login2 4) execute: cc -O ulimit.c -o /bin/login 5) execute: chown root /bin/login execute: chmod 4555 /bin/login *These two commands set the owner and perrmissions so that the ulimit will be set upon login. The following is the ulimit.c program: #include <stdio.h> main (argc,argv) char **argv; { char *ptr; char *largs[3]; char logname[64]; largs[0] = "login"; largs[1] = (char *)strncpy(logname,argv[1],64); largs[2] = NULL; ulimit(2,****); execv("/bin/login2",largs); } ------ Another way that would affect only specific tty lines could be put a line in your /etc/inittab that looks like: 11:1234:respawn:sh -c "ulimit 50000; exec /etc/getty tty11 4800" or 12:1234:respawn:sh -c "ulimit 50000; exec /usr/lib/uucp/uugetty -r tty12 9600" or whatever. Note, these do work on UNIX SysV on AT&T 3b computers and probably on any other UNIX system. ---------- Also, note that if you are using SYSV 3.1 or higher on a 3b2 computer, ULIMIT is a tunable parameter in /etc/master.d/kernel. --Tom Lowe
gwyn@brl-smoke.UUCP (10/03/87)
In article <7501@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >... as far as I can tell /etc/profile is not >used in any way except by user logins via /bin/sh. I just gave /etc/profile as an example. The actual forced ulimit could be established anywhere along the login path. Once lowered, it cannot be raised by a non-superuser. >As for the original problem, can't superuser set the ligit up as >well as down? That IS the original problem! ONLY the super-user can get around the ridiculously small initial ulimit coded into the kernel!
allbery@ncoast.UUCP (10/03/87)
As quoted from <520@drexel.UUCP> by rickers@drexel.UUCP (Rick Wargo): +--------------- | According to the Microport release notes, you cannot have an "infinite" ulimit. | The maximum is about 16 Meg (~ 32000 blocks) | I have yet to try raising it above what they say is the max. Who knows | what can happen? +--------------- I do -- I tried it once, on a Plexus. The "cdlimit" aka ulimit is stored in an int. On the Plexus (a 68000/68020 box, depending), this is a 4-byte quantity; I made the assumption that a negative ulimit was irrational and useless, and set it as if it were unsigned. (Meaning, the value (~0).) Guess what? It was signed. And it treats a negative ulimit as zero. So I couldn't write to _any_ files. I infer that an "int" is 2 bytes in Microport. Therefore, the maximum possible ulimit is 32767. For 680x0 and Vax System V's, the maximum ulimit is 2147483647. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> "`You left off the thunderclap and the lightning flash.', I told him. `Should I try again?' `Never mind.'" --Steven Brust, JHEREG
breck@aimt.UUCP (Robert Breckinridge Beatie) (10/06/87)
In article <6502@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > ...ONLY the super-user can get around > the ridiculously small initial ulimit coded into the kernel! Well, aside from the fact that (according to other articles in this thread) Microport is limited to a maximum file size of 16M (I think?) you might try something like this to get around the ulimit problem for selected users. ----------------------------- #define SHELLPATH "/bin/csh" #define SHELL "-csh" #define LIMIT 3200L long ulimit(); main() { ulimit(2,LIMIT); setuid(getuid()); execl(SHELLPATH,SHELL,0); } ----------------------------- Compile the above program with whatever values for SHELLPATH, SHELL, and LIMIT are appropriate. Then compile the program, chown it to root, and turn on it's setuid bit Then use that program as the shell field of a user's entry in the passwd file. I haven't needed to do this on my system (our default ulimit is set to ~130,000) so this isn't tested. But something along these lines ought to work. I do at least know that from the shell, this command will spawn a sub shell with the ulimit set to the value in LIMIT. Now for a question of my own. Why in the world won't microport support ulimits big enough to write files bigger than 16M? Unix supports files up to four gigabytes. Why did they cripple microport this way? Does it have something to do with the underlying hardware? Or were they trying to eliminate triply indirect blocks in files? Does anyone have the scoop on this? -- Breck Beatie uunet!aimt!breck
jmsully@suprt.UUCP (John M. Sully) (10/07/87)
In article <6475@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <1408@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes: > >What I'm looking for specifically is the patch address(es) for CDLIMIT, > >which limits the maximum write address. Currently, it's set at 2400 blocks > >(1,228,800 bytes), which is way too small a filesize max for an application > > ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely > stupid! Make the initial ulimit "infinite" (it can always be lowered by > any user, typically in /etc/profile if the system administrator so chooses, > but only a superuser can raise it). The patch is: patch /system5 ulpatch xxx where xxx is the max filesize IN BLOCKS. Currently this must be less than 32000, this problem has been fixed in 2.3. -- John M. Sully UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!techs Microport Systems ARPA: uport!techs@ucscc.UCSC.EDU Technical Support
root@uwspan.UUCP (Admin) (10/07/87)
+---- In <98@aimt.UUCP> Robert Breckinridge Beatie writes: | Now for a question of my own. Why in the world won't microport support ulimits | big enough to write files bigger than 16M? Unix supports files up to four | gigabytes. Why did they cripple microport this way? Does it have something to | do with the underlying hardware? Or were they trying to eliminate triply | indirect blocks in files? Does anyone have the scoop on this? +---- In the Official 2.3 release notes I got yesterday there is a comment that the ulimit bug which had limited files to 30000 blocks was fixed, and that now there is no limit on the value for ulimit. 2.3 fixes many of the existing kernel bugs: 9600 baud with no tss faults :-) 80287 exceptions now handled OK The clock is now accurate (and adjustable if you have a fast machine) NEC floppies (fast ones) now work reliably The basic interrupt latency was reduced considerably Shell Layers works - and more -
janm@runx.ips.oz (Jan Mikkelsen) (10/08/87)
In article <7501@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <6475@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >|ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely >|stupid! Make the initial ulimit "infinite" (it can always be lowered by >|any user, typically in /etc/profile if the system administrator so chooses, >|but only a superuser can raise it). > ... >I agree that there should be a simple **well documented** way to change >this. As for the original problem, can't superuser set the ligit up as >well as down? I'm not root on this system and can't try. >-- > bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs | uunet}!steinmetz!crdos1!davidsen >"Stupidity, like virtue, is its own reward" -me But it can be raised! It says so right here in my release notes! All you have to do is type "patch /system5 ulpatch nnn," where 'nnn' is the maximum file size you want in blocks. The maximum supported is 32767 (signed int), giving a 16meg file. Jan Mikkelsen. ACSnet: janm@runx.ips.oz JANET: runx.ips.oz!janm@ukc ARPA: janm%runx.ips.oz@uunet.UU.NET CSNET: janm@runx.ips.oz UUCP: {enea,hplabs,mcvax,prlb2,uunet,ubc-vision,ukc}!munnari!runx.ips.oz!janm "He's dead, Jim."
jpn@teddy.UUCP (John P. Nelson) (10/09/87)
>patch /system5 ulpatch xxx > >where xxx is the max filesize IN BLOCKS. Currently this must be less than >32000, this problem has been fixed in 2.3. Hopefully this is "fixed" by allowing a ulimit of 0, which indicates NO LIMIT AT ALL! V7 could handle HUGE files (via triple indirect blocks). A file limit of 8 Meg or 16 Meg is STUPID! Does anyone know why AT&T botched System V this way?
guy%gorodish@Sun.COM (Guy Harris) (10/10/87)
> Hopefully this is "fixed" by allowing a ulimit of 0, which indicates NO > LIMIT AT ALL! V7 could handle HUGE files (via triple indirect > blocks). A file limit of 8 Meg or 16 Meg is STUPID! Does anyone know > why AT&T botched System V this way? Beats me: System V uses the same file system as V7, with a tweak to allow 512-byte or 1024-byte blocks, so it can handle equally huge files using triple indirect blocks. Maybe the people for whom the predecessor of System V was designed were running PWB/UNIX shops - PWB/UNIX 1.0 had a modified V6 file system, with no doubly-indirect blocks, which meant they had an absolute file size limit of 1MB - and they didn't want these people to have to learn something new, such as how to deal with files larger than 1MB.... Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
ron@topaz.rutgers.edu (Ron Natalie) (10/11/87)
> Maybe the people for whom the predecessor of System V was > designed were running PWB/UNIX shops - PWB/UNIX 1.0 had a modified V6 file > system, with no doubly-indirect blocks, which meant they had an absolute > file size limit of 1MB - and they didn't want these people to have to learn > something new, such as how to deal with files larger than 1MB.... You're memory is failing you. V6 file systems have doubly indirect blocks. You either have eight direct blocks (LARGE bit in mode word = 0), or seven single-indircect (Large bit on), or a huge file. The block number in the inode is used as a double indirect block. The main limitation is that the file size in the inode was 24 bits. (An amuzing V6 bug is that the file offsets were 32 bits, so you could seek to 2^24-1 and write a char and your file would appear to be zero length). Another V6 limitation is that early file systems could not be more than 32,767 blocks long. Careful bug fixing can increase this to full 16 bit block number size. PWB 2.0 used V7 filesystems (I believe, I never saw it).
guy%gorodish@Sun.COM (Guy Harris) (10/11/87)
> You're memory is failing you. V6 file systems have doubly indirect blocks.
No, my memory isn't failing me. V6 file systems had doubly indirect blocks;
however, *PWB/UNIX 1.0* systems didn't. They replaced the doubly indirect
block with an extra singly-indirect block, and eliminated huge files entirely.
Check out the "FILE SYSTEM(V)" manual pages for V6 and PWB/UNIX 1.0; the former
mentions huge files, the latter doesn't.
One mildly amusing aspect of this is that the predecessor to "fsck", called
"fcheck", was distributed in source form with PWB/UNIX 1.0; however, it was
written for V6 file systems, not PWB/UNIX 1.0 file systems.
(Speaking of ancient history, take a look at the 4.3BSD "ar" command,
specifically the set of #defines just before the "longt" routine.)
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.com