[Linux-ivv4] forwarded message from Andrew McNamara

[Stefan Ost]

--lBRaLB6LOx
Content-Type: text/plain; charset=iso-8859-1
Content-Description: message body text
Content-Transfer-Encoding: quoted-printable


Liebe Kolleginnen und Kollegen,=20

Die "64K User Barrier on Linux" scheint auch andere zu nerven, aber das=

Problem scheint komplexer zu sein, als man so denkt.

Viele Gr=FC=DFe=20

Stefan Ost=20


--lBRaLB6LOx
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit

Return-Path: <owner-postfix-users@postfix.org>
Delivered-To: ost@styx.uni-muenster.de
Received: from urix14.uni-muenster.de (URIX14.UNI-MUENSTER.DE [128.176.189.10])
	by styx.uni-muenster.de (Postfix) with ESMTP id DFFA148E
	for <ost@styx.uni-muenster.de>; Fri, 26 Nov 1999 00:45:56 +0100 (MEZ)
Received: from pop2.uni-muenster.de (POP2.UNI-MUENSTER.DE [128.176.188.88])
	by urix14.uni-muenster.de (8.9.3/8.9.3) with ESMTP id AAA30214
	for <ost@pylartes.uni-muenster.de>; Fri, 26 Nov 1999 00:45:56 +0100
Received: from russian-caravan.cloud9.net (russian-caravan.cloud9.net [168.100.1.4])
	by pop2.uni-muenster.de (8.9.3/8.9.3) with ESMTP id AAA32350
	for <Stefan.Ost@uni-muenster.de>; Fri, 26 Nov 1999 00:45:32 +0100
Received: by russian-caravan.cloud9.net (Postfix)
	id 68D09763AA; Thu, 25 Nov 1999 18:41:06 -0500 (EST)
Delivered-To: postfix-users-outgoing@cloud9.net
Received: by russian-caravan.cloud9.net (Postfix, from userid 54)
	id 4A3A5763B3; Thu, 25 Nov 1999 18:41:06 -0500 (EST)
Delivered-To: postfix-users@cloud9.net
Received: from wawura.off.connect.com.au (wawura.off.connect.com.au [202.21.9.2])
	by russian-caravan.cloud9.net (Postfix) with ESMTP id 32729763AA
	for <postfix-users@postfix.org>; Thu, 25 Nov 1999 18:41:05 -0500 (EST)
Received: from melang.off.connect.com.au (melang.off.connect.com.au [202.21.9.1])
	by wawura.off.connect.com.au (Postfix) with ESMTP id 9103C285BC
	for <postfix-users@postfix.org>; Fri, 26 Nov 1999 10:41:03 +1100 (EST)
In-reply-to: Your message of "Thu, 25 Nov 1999 08:56:24 CDT."
             <19991125135624.B0C6D45786@spike.porcupine.org> 
Message-Id: <19991125234103.9103C285BC@wawura.off.connect.com.au>
Precedence: bulk
From: Andrew McNamara <andrewm@connect.com.au>
Sender: owner-postfix-users@postfix.org
To: postfix-users@postfix.org (Postfix users)
Subject: Re: 64K User Barrier on Linux 
Date: Fri, 26 Nov 1999 10:41:03 +1100

>> The filesystem. Ext2 uses a 16-bit datum for UID and GID.
>
>The man is right. I suppose this limits Linux usability as a big
>NFS server.

Here's a message from Theodore Y. Ts'o, the ext2 maintainer, on the
subject:

Date: Sat, 21 Nov 1998 00:35:42 -0500
To: jon.leonard@umich.edu
Cc: linux-kernel@vger.rutgers.edu
From: "Theodore Y. Ts'o" <tytso@mit.edu>
Sender: owner-linux-kernel@vger.rutgers.edu
Subject: Re: High UID support for Linux
In-Reply-To: Jon Leonard's message of Thu, 19 Nov 1998 17:38:39 -0500,
	     <36549DEF.1E8F26EE@umich.edu>
--------

   Date: 	Thu, 19 Nov 1998 17:38:39 -0500
   From: Jon Leonard <jbwl@umich.edu>

   Has anybody looked seriously at supporting 32 bit UIDs on Linux?  We'd
   really like to make Linux a commodity at Umich, but with a user base of
   about 100,000, high UIDs are an absolute requirement.  I've only just
   started looking at this, but scanning the include files, it would appear
   that some platforms already support high UIDs, but not i386.

   Just for grins, I tried changing the typedef in linux/types.h and
   recompiling the kernel.  Wouldn't even boot.  Then I noticed that the
   uid and gid fields in ext2 inodes are 16 bits.  So it seems like this is
   a project, not than a hack. (This was on 2.0.35.)

The ext2 inodes are the smallest part of the problem; there is already
space reserved in the node for the high bytes of the uid and gid
(although every so often I have to tell someone "no" when their favorite
ext2 patch wants to steal those bytes from the inode for their own
purposes).  

The harder thing to do is creating the a system call which returns a 
new stat structure, and then modifying libc to know about this new
system call --- if it happens to be there.  

And of course, checking for all of the other places in the kernel which
might break when changing the size of the uid_t.  I'm actually surprised
the your kernel didn't boot, but there may have been some assembly
language part of the kernel which is dependent on the 16 bit uid.

Anyway, this sounds like a great 2.3 project.  I don't think it's
actually that hard, especially since glibc's stat already supports the
32-bit uid.

						- Ted




--lBRaLB6LOx--