lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  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]
Message-ID: <20081114032531.GI20637@shell>
Date:	Thu, 13 Nov 2008 22:25:31 -0500
From:	Valerie Aurora Henson <vaurora@...hat.com>
To:	Andreas Dilger <adilger@....com>, Theodore Tso <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [RFC PATCH 14/17] super->s_*_blocks_count -> ext2fs_*_blocks_count()

On Thu, Nov 13, 2008 at 01:24:41PM -0700, Andreas Dilger wrote:
> 
> Since it isn't yet common to be able to test > 32-bit blocks
> these bugs may go unnoticed for some time.  It would be nice to be able
> to test 64-bit support easily with e2fsprogs.  Maybe truncate file
> to > 16TB in size (abort if underlying filesystem isn't able to do this),
> use "lazy_bg" or equivalent to avoid writing many GB of data into the
> sparse file, then run e2fsck on it after putting some files at the end.
> This could probably be done by the "script" support in "make check".

Unfortunately, ext4 doesn't support a file this big so you'd have to
deliberately put your e2fsprogs tree on XFS or something like that for
this automatic check to actually help - not a terribly common
situation for an e2fsprogs developer. (I'm doing all my testing on
sparse files on XFS, which definitely chafes - nothing wrong with XFS,
just kind of annoying that I can't self-host e2fsprogs development.)

Hummm... Would it work to use LVM to glue together two loopback
devices backed by files that sum to just over 16TB?

-VAL
--
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