scott@grlab.UUCP (Scott Blachowicz) (04/06/90)
Regarding /usr/spool/news on multiple disks; gam@netcom.uucp (Gordon Moffett) writes: > NetCom would like to divide /usr/spool/news among multiple disks, > but it turns out that B News 2.11.19 doesn't handle that really well, > as it expects to links to all the articles into place from /usr/spool/news/.tmp. > I'm suprised more people haven't encounted this problem, when you can only > put 60000 inodes on a single disk. ...when YOU can only put 60000 inodes... One of our file systems (we run HP-UX) has "159744 total i-nodes". We're currently only using ~46000 of them, but I assume that many wouldn't get allocated if we couldn't use them. There BETTER not be any 60000 limititation. Maybe you need to re-init the file system to get more inodes (assuming you're not running out of disc space in general). > I took the fcopy() code from expire.c and had inews do the fcopy() > if the call to link(2) failed because of cross-device links. It would be nice to try linking to all of the cross-posts before punting to fcopy(). At least that way there would only be one copy of the article per file system. Or maybe there's some way to use symbolic links on system that have those. > Has anyone else had this kind of problem? If so, what have you done to allow > news on multiple disks? I'd be interested in hearing about this, too. -- Scott Blachowicz E-mail: scott@grlab.UUCP USPS: Graphicus ..or.. ...!hpubvwa!grlab!scott 150 Lake Str S, #206 VoicePh: 206/828-4691 Kirkland, WA USA 98033 FAX: 206/828-4236
henry@utzoo.uucp (Henry Spencer) (04/08/90)
In article <SCOTT.90Apr6083757@gr375.grlab.UUCP> scott@grlab.UUCP (Scott Blachowicz) writes: >> I'm suprised more people haven't encounted this problem, when you can only >> put 60000 inodes on a single disk. >...when YOU can only put 60000 inodes... One of our file systems (we >run HP-UX) has "159744 total i-nodes". We're currently only using >~46000 of them, but I assume that many wouldn't get allocated if we >couldn't use them. There BETTER not be any 60000 limititation.... Old Unixes used 16-bit inode numbers in directory entries, making it inherently impossible to have more than 64K-1 inodes per filesystem. Most System Vs in the field still have this restriction. -- Apollo @ 8yrs: one small step.| Henry Spencer at U of Toronto Zoology Space station @ 8yrs: .| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@auspex.auspex.com (Guy Harris) (04/08/90)
>> I'm suprised more people haven't encounted this problem, when you can only >> put 60000 inodes on a single disk. >...when YOU can only put 60000 inodes... One of our file systems (we >run HP-UX) ...which means you probably have a BSD-flavored file system. The V7 file system that System III and System V, among other systems, use stores inumbers in directory entries as 16-bit quantities (unless you have "unsigned short"s that aren't 16 bits long, or something odd like that). Thus, you're limited to 65535 inodes. The BSD file system that other systems - including System V Release 4 - use stores them as 32-bit quantities.
jonl (frederick smythe, esquire) (04/10/90)
+-I seem to recall scott@grlab.UUCP (Scott Blachowicz) writing: | >Has anyone else had this kind of problem? If so, what have you done to allow | >news on multiple disks? | I'd be interested in hearing about this, too. it is a fairly simple re-organization to the bnews code to change all calls to link to ones own function which will attempt a link, and if it fails, will copy the file over and make the perms/access time etc, the same as possible. i have done this successfully on bnews under sco xenix. i imagine that it could be done even more elegantly under systems with symbolic links (assuming that they have the same inode per filesystem limits). -- jon luini, jonl@sco.com sco usenet administration