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

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

Hi,

> > > On the other hand, for a fairly fat .config which has 17 filesystems in
> > > .vmlinux:
> > >
> > >    text    data     bss     dec     hex filename
> > > 4633032 1011304  248288 5892624  59ea10 vmlinux		CONFIG_LSF=y
> > > 4633680 1011304  248288 5893272  59ec98 vmlinux		CONFIG_LSF=n
> > >
> > > It's probably less 0.5 kbytes for usual embedded .config.
> > > I just don't think the benefit of CONFIG_LSF outweighs its costs.

I looked into the number of struct inode on slab of x86
in cases i_blocks is both 4 bytes and 8 bytes.
As the following tables, the number of inodes per slab is the same
in both cases.  So at least on x86, there seems to be no influence for
the memory usage by extending inode->i_blocks.

In default configuration (CONFIG_QUOTA=ON, CONFIG_INOTIFY=ON):
-------------------------------------------------------------
In case inode->i_blocks is unsigned long
                size of inode(byte)     the number per slab
ext2_inode_info        588                       6
ext3_inode_info        612                       6

In case inode->i_blocks is unsigned long long
                size of inode(byte)    the number per slab
ext2_inode_info        592                       6
ext3_inode_info        616                       6
--------------------------------------------------------------

CONFIG_QUOTA=OFF, CONFIG_INOTIFY=OFF:
-------------------------------------------------------------
In case inode->i_blocks is unsigned long
                size of inode(byte)    the number per slab
ext2_inode_info             540                  7
ext3_inode_info             564                  7

In case inode->i_blocks is unsigned long long
                size of inode(byte)    the number per slab
ext2_inode_info             544                  7
ext3_inode_info             568                  7
--------------------------------------------------------------

> > Two options exist IMHO:
> > - remove the new CONFIG_* parameters and stick with CONFIG_LBD (this could
> >   still use a separate type from sector_t if desired) to reduce the amount
> >   of testing combinations needed
> > - make the new CONFIG_* default to on and allow it to be disabled with
> >   CONFIG_BASE_SMALL
>
> Well yes, but we still have the printk problem.
>
> CONFIG_LFS would become a specialised option for embedded systems and
> for the minority of people who self-compile kernels.  I just don't
> think that's worth the maintainability hassle.

I added CONFIG_LSF to use large filesystem over network with >2TB file
even on a small system as CONFIG_LBD disable.  And I heard that some
people dislike network filesystems depending on block device.

Trond, do you have comments about integrating CONFIG_LFS and
CONFIG_LBD?

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