[Top] [All Lists]

Re: Filestreams (and 64bit inodes)

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Filestreams (and 64bit inodes)
From: Greg Banks <gnb@xxxxxxxxxxxxxxxxx>
Date: Fri, 13 Jun 2008 13:24:30 +1000
Cc: Timothy Shimmin <tes@xxxxxxx>, Richard Scobie <richard@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4851E41C.6050108@xxxxxxxxxxx>
Organization: File Serving Technologies ; Silicon Graphics Inc.
References: <484B15A3.4030505@xxxxxxxxxxx> <484CA425.3080606@xxxxxxxxxxx> <484DDDB3.70000@xxxxxxx> <484F0998.90306@xxxxxxxxxxx> <484F2CD7.9070506@xxxxxxx> <484F452A.8090909@xxxxxxxxxxx> <48512A34.1020604@xxxxxxxxxxx> <4851CD32.7080106@xxxxxxxxxxxxxxxxx> <4851E41C.6050108@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (X11/20060911)
Eric Sandeen wrote:
> Heh :)  At first I was just going to correlate with st_ino users to cut
> it down, but then I learned that glibc will actually give you an
> EOVERFLOW if, say st_ino overflows, even if you were only going to check
> st_mode.  :(  So pretty much everything needs fixing.
Of course. There's no way for the app to tell glibc that the app doesn't
care about st_ino, so glibc must assume that glibc needs to return an
accurate st_ino.  The alternative is to return the lower 32 bits of
st_ino, thus causing silent subtle failures in the very small number of
applications which actually do something with st_ino.  This is what
glibc used to do back when I first started tracking the issue.
> (FWIW I gathered statfs/statvfs calls, too...)

Greg Banks, P.Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.

<Prev in Thread] Current Thread [Next in Thread>