On Mon, Oct 30, 2000 at 02:16:59PM -0800, H. Peter Anvin wrote:
> Having the kernel translate inode numbers can easily kill your system by
> eating all your kernel memory...
Would a callout similar to the arpd solution work?
mrc
--
Mike Castle Life is like a clock: You can work co
Date: Mon, 30 Oct 2000 17:03:12 -0800
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
I could definitely agree with this. time_t needs to go 64 bits too,
although we have a little more time for that...
Sorry, we don't have more time. NFSv3 already supports time values
that cannot be sto
> Date: Tue, 31 Oct 2000 03:00:43 +0200
> From: Matti Aarnio <[EMAIL PROTECTED]>
> The more I am following this disaster called ABI evolution, the more
> I am convinced that IBM did indeed do something right at the switch
> from AIX 3.x to AIX 4.x -- ALL SCALAR INTEGERS AT AIX 4.x A
On Tue, Oct 31, 2000 at 03:00:43AM +0200, Matti Aarnio wrote:
> For some things even 64 bits are not enough
I tend to think that time_t is an example.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Matti Aarnio <[EMAIL PROTECTED]> writes:
> We had this 64-bits-or-not discussion with Ulrich back when 2.1 was
> imminent, and he was utterly convinced that it is good to save space
> at various LFS related structure fields.
The LFS data structures are fine. Inform yourself before compla
On Mon, 30 Oct 2000, H. Peter Anvin wrote:
> UTF-16 is utter crap, anyway. UTF-8 or UCS-4/UTF-32 are the only sane
> encodings of Unicode (one multibyte, one wide. UTF-16 combines the
> advantages of neither and the disadvantages of both.)
No arguments. I would prefer UTF-8 - much easier to
Alexander Viro wrote:
>
> On Tue, 31 Oct 2000, Matti Aarnio wrote:
>
> > Something along the lines of: As we no longer have access control
> > in form of having magic UIDs, e.g. zero vs. non-zero, we could as well
> > begin to use UTF-16 UNICODE 3.0 encoded strings for UID referral in
> >
On Tue, 31 Oct 2000, Matti Aarnio wrote:
> Something along the lines of: As we no longer have access control
> in form of having magic UIDs, e.g. zero vs. non-zero, we could as well
> begin to use UTF-16 UNICODE 3.0 encoded strings for UID referral in
> fixed size arrays giving us inst
Matti Aarnio wrote:
>
> We had this 64-bits-or-not discussion with Ulrich back when 2.1 was
> imminent, and he was utterly convinced that it is good to save space
> at various LFS related structure fields. Now that is coming to haunt
> us... (I distinctly recall of him mentioning of re
On Mon, Oct 30, 2000 at 02:39:27PM -0800, Ulrich Drepper wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Fair enough. However, the question still remains if we should make it
> > the default and make the old heterogenous API the explicit option.
>
> Sure, this can be done. When the
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> > The only other approach I can think of is to simply have stat() (and
> > fstat and so on) fail on files with inode numbers that don't fit in 32
> > bits. The effect would be that you couldn't use most non-LFS programs
> > on certain NFS v3/v4 file
Geoff Keating wrote:
>
> > Date: Mon, 30 Oct 2000 13:57:46 -0800
> > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
>
> > Yes, of course. However, some filesystems will have large inode numbers
> > for all, or nearly all, files.
>
> Then those filesystems will be unusable for applications that hav
> Date: Mon, 30 Oct 2000 13:57:46 -0800
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Yes, of course. However, some filesystems will have large inode numbers
> for all, or nearly all, files.
Then those filesystems will be unusable for applications that have a
32-bit ino_t. There's no way arou
Geoff Keating wrote:
> >
> > This isn't a choice for a lot of people; again, NFS v3/v4 requires this.
> >
> > Having the kernel translate inode numbers can easily kill your system by
> > eating all your kernel memory...
>
> The only other approach I can think of is to simply have stat() (and
> fs
> Date: Mon, 30 Oct 2000 14:16:59 -0800
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Organization: Transmeta Corporation
> X-Accept-Language: en, sv, no, da, es, fr, ja
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>
> Geoff Keating wrote:
> >
> > I would recommend no
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Fair enough. However, the question still remains if we should make it
> the default and make the old heterogenous API the explicit option.
Sure, this can be done. When the time comes. Certainly not in glibc
2.2. This always was the plan and sinc
Mark Kettenis wrote:
>
>Date: Mon, 30 Oct 2000 14:08:44 -0800
>From: "H. Peter Anvin" <[EMAIL PROTECTED]>
>
>If so, we'd be better off completely deprecating the old calls and make
>the LFS calls the default calls (and off_t == off64_t, ino_t == ino64_t,
>etc.)
>
> Except th
Date: Mon, 30 Oct 2000 14:08:44 -0800
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
If so, we'd be better off completely deprecating the old calls and make
the LFS calls the default calls (and off_t == off64_t, ino_t == ino64_t,
etc.)
Except that the LFS calls aren't completely imple
Ulrich Drepper wrote:
>
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Sorry for being picky, but LFS, specifically, means using an heterogenous
> > API using seek64() instead of lseek() and so on and so forth.
>
> Wrong. LFS also includes -D_FILE_OFFSET_BITS=64 which transparently
> rep
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Sorry for being picky, but LFS, specifically, means using an heterogenous
> API using seek64() instead of lseek() and so on and so forth.
Wrong. LFS also includes -D_FILE_OFFSET_BITS=64 which transparently
replaces the non-LFS types and functions.
Geoff Keating wrote:
>
> I would recommend not designing such filesystems, or not using them,
> or having the kernel translate inode numbers.
>
This isn't a choice for a lot of people; again, NFS v3/v4 requires this.
Having the kernel translate inode numbers can easily kill your system by
eati
> Date: Mon, 30 Oct 2000 13:57:46 -0800
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Yes, of course. However, some filesystems will have large inode numbers
> for all, or nearly all, files.
Then systems with such filesystems will not be backwards-compatible
with older linux applications or no
Ben LaHaise wrote:
>
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> > filesystems.
> >
> > Ideas, anyone?
>
> Don't use filesystems that require 64 bit inode numbers until all
> applications are using LFS. Personally I
On Mon, 30 Oct 2000, H. Peter Anvin wrote:
> 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> filesystems.
>
> Ideas, anyone?
Don't use filesystems that require 64 bit inode numbers until all
applications are using LFS. Personally I'd rather LFS not be an option
anymore
Geoff Keating wrote:
>
> > Date: Mon, 30 Oct 2000 11:29:09 -0800
> > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
>
> > I believe I wrote this back as well: this will affect *ALL* applications,
> > even those that don't need large file support. This change really needs
> > to happen, or any non-L
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> filesystems.
I have Cc:'d this to the linux-fs-devel list; hopefully we can get some
communication going.
Mark Kettenis wrote:
>
>I believe I wrote this back as well: this will affect *ALL* applications,
>even those that don't need large file support. This change really needs
>to happen, or any
27 matches
Mail list logo