> > Note that there is one place where 64 bits is simply _too_ expensive, and
> > that's the page cache. In particular, the "index" in "struct page". We
> > want to make "struct page" _smaller_, not larger.
> > Right now that means that 16TB really is a hard limit for at least some
> > device access on a 32-bit machine with a 4kB page-size (yes, you could
> > make a filesystem that is bigger, but you very fundamentally cannot make
> > individual files larger than 16TB).
> ITYM "8Tb" - indices are signed, IIRC. OTOH, it's not 2^31 * PAGE_SIZE -
> it's 2^31 * PAGE_CACHE_SIZE, which can be bigger.
> Al, still thinking that anybody who does mkfs.<whatever> on a multi-Tb
> device should seek professional help of the kind they don't give on
Its Linux's job to make this work. If I happen to own 20 120GB disks,
whats wrong with just mkfs on them? If mkfs.ext3 on 2TB array is
reason for seeking profesional help, then there's something wrong with
-- Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/