lkml.org 
[lkml]   [2006]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 2/3] Fix problems on multi-TB filesystem and file
Date
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/

\
 
 \ /
  Last update: 2006-01-13 14:53    [W:0.361 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site