Messages in this thread | | | From | "Takashi Sato" <> | Subject | RE: [PATCH 2/3] Fix problems on multi-TB filesystem and file | Date | Fri, 13 Jan 2006 22:50:19 +0900 |
| |
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/
| |