Re: stat64 for over 2TB file returned invalid st_blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Dec 03, 2005  22:00 +0900, Takashi Sato wrote:
Andreas Dilger wrote:
>Actually, it should probably be "sector_t", because it isn't really
>possible to have a file with more blocks than the size of the block
>device.  This avoids memory overhead for small systems that have no
>need for it in a very highly-used struct.  It may be for some network
>filesystems that support gigantic non-sparse files they would need to
>enable CONFIG_LBD in order to get support for this.

I think sector_t is ok for local filesystem as you said.  However,
on NFS, there may be over 2TB file on server side, and inode.i_blocks
for over 2TB file will become invalid on client side in case CONFIG_LBD
is disabled.

I don't know the exact specs of NFS v2 and v3, but I doubt they can have
single files larger than 2TB.  Even if they could then this is not a

I believe NFS v3 can handle over 2TB file. :-)

very common situation and if someone is running in such an environment
then they can easily enable CONFIG_LBD (or make e.g. CONFIG_NFS_V4 have
a dependency to enable this if it is important enough).  What I'd rather
avoid is needless growth of heavily-used structures for rather uncommon
cases (at the current time at least, this can be re-examined later).

I agree above.

It might also be possible to have a separate CONFIG_LSF (or whatever)
that enables support for large single files, maybe enabled by default
with CONFIG_LBD and also configurable separately for clients of network
filesystems with large single files.  Someone who cares more about the
proliferation of configuration options than I can decide whether it
makes sense to keep these as separate options.

I don't think CONFIG_LBD should determine whether large single
files is enabled.  So, I agree your suggestion basically.
It would be nice if there was a suitable configuration option for it.
I will examine the implementation in detail.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux