On Jan 08, 2008 14:33 -0500, Josef Bacik wrote:
> @@ -190,8 +190,13 @@ errcode_t ext2fs_get_device_size(const c
> ioctl(fd, BLKGETSIZE64, &size64) >= 0) {
> if ((sizeof(*retblocks) < sizeof(unsigned long long)) &&
> ((size64 / blocksize) > 0xFFFFFFFF)) {
> - rc = EFBIG;
> - goto out;
> + /* 16tb fs is fine, just adjust slightly */
> + if ((size64 / blocksize) == 0x100000000) {
> + size64--;
> + } else {
> + rc = EFBIG;
> + goto out;
> + }
It might be cleaner to localize this check/fixup into a small helper function?
> +++ e2fsprogs/misc/mke2fs.c
> @@ -1455,13 +1455,6 @@ static void PRS(int argc, char *argv[])
> - if (!force && fs_param.s_blocks_count >= ((unsigned) 1 << 31)) {
> - com_err(program_name, 0,
> - _("Filesystem too large. No more than 2**31-1 blocks\n"
> - "\t (8TB using a blocksize of 4k) are currently supported."));
> - exit(1);
> - }
> -
> if ((blocksize > 4096) &&
> (fs_param.s_feature_compat & EXT3_FEATURE_COMPAT_HAS_JOURNAL))
> fprintf(stderr, _("\nWarning: some 2.4 kernels do not support "
It is also worthwhile to report at least a warning for filesystems larger
than 0x7fffffff blocks that older kernels (2.6.18 and older, IIRC) don't
necessarily work correctly with such large filesystems.
Doing something like having mke2fs zero out block 1, flush it from cache
with ioctl(BLKFLSBUF), then write some data at 8TB+1 to verify it doesn't
clobber block 1 might also be prudent. I've seen some RAID arrays do this
in the past, and when we pass 0xffffffff blocks we should do the same so
it may as well be a simple helper function.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-
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
