On Thu, 2005-12-08 at 20:38 +0900, Takashi Sato wrote:
> I prefer sector_t for i_blocks rather than newly defined blkcnt_t.
> The reasons are:
>
> - Both i_blocks and common sector_t are for on-disk 512-byte unit.
> In this point of view, they have the same character.
One is a count of the number of blocks used by a file, and exists only
in order to help filesystems cache this value. The other is a handle to
a block. How is that the same?
> - If we created the type blkcnt_t newly, the patch would have to
> touch a lot of files as follows, like sector_t does.
> block/Kconfig, asm-i386/types.h, asm-x86_64/types.h,
> asm-ppc/types.h, asm-s390/types.h, asm-sh/types.h,
> asm-h8300/types.h, asm-mips/types.h
> It will be simple if we use sector_t for i_blocks.
That is not a particularly good reason.
> Also, I cannot imagine the situation that > 2TB files are used over
> network with CONFIG_LBD disabled kernel. Is there such a thing
> realistically?
Apart from this and the kstat wart, there is no reason to set CONFIG_LBD
for a networked filesystem. Why would you want to buy a > 2TB local disk
on an HPC cluster node if you already have a server?
I suppose we can make NFS use a private field instead, and just set
i_blocks to 0, but that's unnecessarily wasteful too.
Cheers,
Trond
-
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]
