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