lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 8 Jan 2008 16:02:16 -0700
From:	Andreas Dilger <adilger@....com>
To:	Josef Bacik <jbacik@...hat.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsprogs: play with 8TB to 16TB fs's better

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ