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

[Andrew Morton]

Andreas Dilger <adilger@xxxxxxxxxxxxx> wrote:
>
> On Jan 13, 2006  12:28 -0800, Andrew Morton wrote:
> > So now we're proposing to repeat the sector_t problem with a bunch of new
> > fields.  Fortunately we're less likely to be putting these particular
> > fields into printk statements but I note that CIFS (at least) has a couple
> > such statements and with your patch they're now generating warnings (and
> > potential runtime bugs).
> > 
> > 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.
> 
> We were originally going to use CONFIG_LBD, but there were some complaints
> that "sector_t" isn't the right variable to use for this, even though they
> are remarkably close.  That would at least remove one config change.
> 
> I don't think the cost is in the vmlinux itself, but rather that having a
> long long for i_blocks is overkill for any but the very largest systems
> (Lustre has been running fine w/o this, at the expense of some accuracy
> for the i_blocks count on many-TB files).  Growing struct inode for these
> 0.0000001% of systems is probably harmful for small systems, given how
> many inodes are used in a system.

I'd expect that rh and suse and others will turn on the >2TB option, so
that's most systems.

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

Ho hum.  But then, people don't printk these fields as much.  I spose we
could live with your option 1).  And we need to find all those places (like
CIFS) which are presently trying to print a blkcnt_t and add the %llu and
the typecast.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/