RE: [PATCH 2/3] Fix problems on multi-TB filesystem and file

["Takashi Sato" <sho@tnes.nec.co.jp>]

Hi,

> >  This is a patch to add blkcnt_t as the type of inode.i_blocks.
> >  This enables you to make the size of blkcnt_t either 4 bytes or 8 bytes
> >  on 32 bits architecture with CONFIG_LSF.
>
> What was the rationale behind CONFIG_LSF?  It's a bit of an ugly thing and
> I'm wondering if we wouldn't be better off just removing it and simply
> fixing >2TB support for all .configs?

We should avoid needless growth of heavily-used structure such as
inode for a small system like embedded system.
So I make it possible to configure the size of i_blocks with CONFIG_LSF.

> Do the common userspace tools need to be updated for this, or do they
> already get it right?

glibc's st_blocks is always 8 bytes as below.

__blkcnt64_t st_blocks;

On the original kernel, a padding for st_blocks is set at appropriate
location for each endian types as below.
So, there is no need to fix user program(glibc).

include/asm-i386/stat.h:
--------------------------------------------------------------------------
unsigned long   st_blocks;      /* Number 512-byte blocks allocated. */
unsigned long   __pad4;         /* future possible st_blocks high bits */
---------------------------------------------------------------------------

include/asm-m68k/stat.h:
--------------------------------------------------------------------------
unsigned long   __pad4;         /* future possible st_blocks high bits */
unsigned long   st_blocks;      /* Number 512-byte blocks allocated. */
--------------------------------------------------------------------------

-- Takashi Sato


-
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/