Re: stat64 for over 2TB file returned invalid st_blocks

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Tue, 2005-12-06 at 08:30 -0600, Dave Kleikamp wrote:
> On Tue, 2005-12-06 at 21:42 +0900, Takashi Sato wrote:
> > I realized some 32-bit big-endian architectures such as sh and m68k
> > have a padding before 32-bit st_blocks, though mips and ppc have
> > 64-bit st_blocks.
> > 
> > - asm-sh
> > #if defined(__BIG_ENDIAN__)
> >         unsigned long   __pad4;         /* Future possible st_blocks hi bits */
> >         unsigned long   st_blocks;      /* Number 512-byte blocks allocated. */
> > #else /* Must be little */
> >         unsigned long   st_blocks;      /* Number 512-byte blocks allocated. */
> >         unsigned long   __pad4;         /* Future possible st_blocks hi bits */
> > #endif
> > 
> > - asm-m68k
> >         unsigned long   __pad4;         /* future possible st_blocks high bits */
> >         unsigned long   st_blocks;      /* Number 512-byte blocks allocated. */
> > 
> > So I updated the patch.  Any feedback and comments are welcome.
> 
> I think it looks good.  The only issue I have is that I agree with
> Andreas that i_blocks should be of type sector_t.  I find the case of
> accessing very large files over nfs with CONFIG_LBD disabled to be very
> unlikely.

NO! sector_t is a block-device specific type. It does not belong in the
generic inode.

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/