Valerie Clement wrote: > Jose R. Santos wrote: >> I think this has more to do with the fact that I'm on a 32bit >> architecture and there are still a couple places where blocks are >> represented using "unsigned long". I'm trying to get access to a 64bit >> arch to confirm this. >> >> -JRS >> > Oh, I didn't catch that you use a 32-bit system. > On 32-bit architectures, the page cache index size imposes a 16TB limit > on the filesystem size (with 4KB blocksize). So you need a 64-bit system > for your test. > Valérie hm, the mount never should have gotten far enough to fail due to this, should it have? Jose, what exactly failed? I see references to debugfs failing, but also kernel logs... Things like debugfs will have issues with very large block devices due to maximum file size restrictions on 32-bit platforms, due to the page cache issue Valerie mentions... But trying to open it should give EFBIG I'd think? And mounting such a filesystem on a 32-bit system should also get rejected early (and cleanly). Jose, you mentioned that some blocks are still "unsigned long" on 32-bits... they shouldn't be, the LBD work should have fixed all those long ago. But there is still the 16TB page cache limit in force. -Eric - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html