NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/43908
The following reply was made to PR kern/43908; it has been noted by GNATS.
From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
arto.huusko%pp2.inet.fi@localhost
Cc:
Subject: Re: kern/43908
Date: Tue, 2 Nov 2010 17:20:53 -0400
On Nov 2, 7:35pm, arto.huusko%pp2.inet.fi@localhost (Arto Huusko) wrote:
-- Subject: Re: kern/43908
| The following reply was made to PR kern/43908; it has been noted by GNATS.
|
| From: Arto Huusko <arto.huusko%pp2.inet.fi@localhost>
| To: gnats-bugs%NetBSD.org@localhost
| Cc:
| Subject: Re: kern/43908
| Date: Tue, 02 Nov 2010 21:32:02 +0200
|
| Presumably, when running 32 bit glibc on top of a really 32 bit linux
| kernel, linux never returns inode numbers over 32 bits. So not a glibc
| bug.
|
| However, unless smaller inode numbers for tmpfs are not possible, I
| understand this a bug that is not feasible to fix in NetBSD's
| linux32 emulation. To mitigate this:
|
| - document this in bugs section of compat_linux
| - possibly warn about this in the same way as with too large
| directory offset cookies
I don't see why we cannot deal with this in a sane way. Perhaps even
as kludgy as to have a tmpfs flag not to generate large inodes...
christos
Home |
Main Index |
Thread Index |
Old Index