On Thursday 03 March 2005 10:19, Andi Kleen wrote:
> On Wed, Mar 02, 2005 at 08:53:07AM -0800, Trond Myklebust wrote:
> > on den 02.03.2005 Klokka 12:33 (+0100) skreiv Bernd Schubert:
> > > > I can see no good reason for truncating inode number values on
> > > > platforms that actually do support 6
On Thu, Mar 03, 2005 at 01:37:26PM -0800, Trond Myklebust wrote:
> to den 03.03.2005 Klokka 10:19 (+0100) skreiv Andi Kleen:
> > The problem here is that glibc uses stat64() which supports
> > 64bit inode numbers. But glibc does the overflow checking itself
> > and generates the EOVERFLOW in user s
to den 03.03.2005 Klokka 22:46 (+0100) skreiv Andi Kleen:
> > As far as the kernel is concerned, asm/posix_types defines
> > __kernel_ino_t as "unsigned long" on most platforms (except a few which
> > define is as "unsigned int). We don't care what size type glibc itself
> > uses.
>
> That could
to den 03.03.2005 Klokka 10:19 (+0100) skreiv Andi Kleen:
> The problem here is that glibc uses stat64() which supports
> 64bit inode numbers. But glibc does the overflow checking itself
> and generates the EOVERFLOW in user space. Nothing we can do
> about that. The 64bit inodes work under 32bit t
> So what do you actually suggest? On the one hand you say even 32bit userspace
> supports 64bit inodes, if it wants. On the other hand you say the truncation
> needs to be done on file system level.
> To my mind this is contradicting, the first statement suggests to do the
> truncation in user
On Wed, Mar 02, 2005 at 08:53:07AM -0800, Trond Myklebust wrote:
> on den 02.03.2005 Klokka 12:33 (+0100) skreiv Bernd Schubert:
>
> > > I can see no good reason for truncating inode number values on platforms
> > > that actually do support 64-bit inode numbers, but I can see several
> >
> > Well
On Wed, Mar 02, 2005 at 01:13:38AM -0800, Trond Myklebust wrote:
> on den 02.03.2005 Klokka 09:18 (+0100) skreiv Andi Kleen:
> > On Wed, Mar 02, 2005 at 12:46:23AM +0100, Andreas Schwab wrote:
> > > Bernd Schubert <[EMAIL PROTECTED]> writes:
> > >
> > > > Hmm, after compiling with -D_FILE_OFFSET_B
On Wednesday 02 March 2005 17:53, Trond Myklebust wrote:
> on den 02.03.2005 Klokka 12:33 (+0100) skreiv Bernd Schubert:
> > > I can see no good reason for truncating inode number values on
> > > platforms that actually do support 64-bit inode numbers, but I can see
> > > several
> >
> > Well, at l
on den 02.03.2005 Klokka 12:33 (+0100) skreiv Bernd Schubert:
> > I can see no good reason for truncating inode number values on platforms
> > that actually do support 64-bit inode numbers, but I can see several
>
> Well, at least we would have a reason ;)
A 32-bit emulation mode is clearly a "p
On Wednesday 02 March 2005 10:13, Trond Myklebust wrote:
> on den 02.03.2005 Klokka 09:18 (+0100) skreiv Andi Kleen:
> > On Wed, Mar 02, 2005 at 12:46:23AM +0100, Andreas Schwab wrote:
> > > Bernd Schubert <[EMAIL PROTECTED]> writes:
> > > > Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works
on den 02.03.2005 Klokka 09:18 (+0100) skreiv Andi Kleen:
> On Wed, Mar 02, 2005 at 12:46:23AM +0100, Andreas Schwab wrote:
> > Bernd Schubert <[EMAIL PROTECTED]> writes:
> >
> > > Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works fine. But why
> > > does
> > > it work without this optio
On Wed, Mar 02, 2005 at 12:46:23AM +0100, Andreas Schwab wrote:
> Bernd Schubert <[EMAIL PROTECTED]> writes:
>
> > Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works fine. But why
> > does
> > it work without this option on a 32bit kernel, but not on a 64bit kernel?
>
> See nfs_fileid_to
Bernd Schubert <[EMAIL PROTECTED]> writes:
> Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works fine. But why does
> it work without this option on a 32bit kernel, but not on a 64bit kernel?
See nfs_fileid_to_ino_t for why the inode number is different between
32bit and 64bit kernels.
An
Bernd Schubert <[EMAIL PROTECTED]> writes:
> Hmm, after compiling with -D_FILE_OFFSET_BITS=64 it works fine. But why does
> it work without this option on a 32bit kernel, but not on a 64bit kernel?
Most likely the inode number (which is the only non-filesize related item
that is different betwee
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Tue, Mar 01, 2005 at 11:10:38PM +0100, Andreas Schwab wrote:
>> That's because there are some values in the stat64 buffer delivered by the
>> kernel which cannot be packed into the stat buffer that you pass to stat.
>> Use stat64 or _FILE_OFFSET_BITS=64.
On Tuesday 01 March 2005 23:10, Andreas Schwab wrote:
> Bernd Schubert <[EMAIL PROTECTED]> writes:
> >> It is most likely some kind of user space problem. I would change
> >> it to int err = stat(dir, &buf);
> >> and then go through it with gdb and see what value err gets assigned.
> >>
> >> I can
> stat64("/mnt/test/yp", {st_mode=S_IFDIR|0755, st_size=2704, ...}) = 0
It returns 0. No error. Someone else in user space must be adding the
EOVERFLOW.
glibc code does quite a lot of strange things with stat, perhaps
it comes from there.
> write(2, "err = -1\n", 9err = -1
> ) = 9
> strace didn't say so, and normally it doesn't lie about things like this.
Well, I show you the updated source code and strace output and if you still
don't believe me, ask me for a login to our system ;)
#include
#include
#include
#include
#include
#include
#include
int main(int argc
On Tue, Mar 01, 2005 at 11:10:38PM +0100, Andreas Schwab wrote:
> That's because there are some values in the stat64 buffer delivered by the
> kernel which cannot be packed into the stat buffer that you pass to stat.
> Use stat64 or _FILE_OFFSET_BITS=64.
If that had been the case strace would have
Bernd Schubert <[EMAIL PROTECTED]> writes:
>> It is most likely some kind of user space problem. I would change
>> it to int err = stat(dir, &buf);
>> and then go through it with gdb and see what value err gets assigned.
>>
>> I cannot see any kernel problem.
>
> The err value will become -1 here
On Tue, Mar 01, 2005 at 10:07:01PM +0100, Bernd Schubert wrote:
> Hello Andi,
>
> sorry, due to some mail sending/refusing problems, I had to resend to the
> nfs-list, which prevented the answers there to be posted to the other CCs.
>
> > It is most likely some kind of user space problem. I wou
Hello Andi,
sorry, due to some mail sending/refusing problems, I had to resend to the
nfs-list, which prevented the answers there to be posted to the other CCs.
> It is most likely some kind of user space problem. I would change
> it to int err = stat(dir, &buf);
> and then go through it with g
> 32bit:
> --
> hitchcock:/home/bernd/src/tests# strace32 ./test_stat32 /mnt/test/yp
> execve("./test_stat32", ["./test_stat32", "/mnt/test/yp"], [/* 39 vars */]) =
> 0
> uname({sys="Linux", node="hitchcock", ...}) = 0
> brk(0) = 0x80ad000
> brk(0x80ce000)
> As usual we are using unfs3 for /etc and /var, but for me that looks like a
> client problem. I'm even not sure if this is limited to NFS at all.
Sorry, that was easy to test, of course. This problem doesn't seem to exist on
a local disk.
-
To unsubscribe from this list: send the line "unsubsc
Hi,
I'm just looking into a very strange problem. Some of our systems have
athlon64 CPUs. Due to our diskless nfs environment we currently still prefer
a 32bit userspace environment, but would like to be able to use a 64-bit
chroot environment.
Well, currently there seems to be a stat64() NFS
25 matches
Mail list logo
