Messages in this thread | | | Date | Fri, 13 Jan 2006 13:51:52 -0700 | From | Andreas Dilger <> | Subject | Re: [PATCH 2/3] Fix problems on multi-TB filesystem and file |
| |
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.
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
Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
- 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/
| |