Andreas Dilger <[email protected]> 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 [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]
