2001-07-04 22:04:58 +04:00
|
|
|
/*
|
|
|
|
* This testing program makes sure the bitops functions work
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001 by Theodore Ts'o.
|
2008-08-28 07:07:54 +04:00
|
|
|
*
|
2001-07-04 22:04:58 +04:00
|
|
|
* %Begin-Header%
|
2010-05-18 05:31:56 +04:00
|
|
|
* This file may be redistributed under the terms of the GNU Library
|
|
|
|
* General Public License, version 2.
|
2001-07-04 22:04:58 +04:00
|
|
|
* %End-Header%
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
#if HAVE_UNISTD_H
|
|
|
|
#include <unistd.h>
|
|
|
|
#endif
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <time.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#if HAVE_ERRNO_H
|
|
|
|
#include <errno.h>
|
|
|
|
#endif
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
#include <sys/time.h>
|
|
|
|
#include <sys/resource.h>
|
2001-07-04 22:04:58 +04:00
|
|
|
|
|
|
|
#include "ext2_fs.h"
|
|
|
|
#include "ext2fs.h"
|
|
|
|
|
|
|
|
unsigned char bitarray[] = {
|
|
|
|
0x80, 0xF0, 0x40, 0x40, 0x0, 0x0, 0x0, 0x0, 0x10, 0x20, 0x00, 0x00
|
|
|
|
};
|
|
|
|
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
int bits_list[] = {
|
|
|
|
7, 12, 13, 14,15, 22, 30, 68, 77, -1,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define BIG_TEST_BIT (((unsigned) 1 << 31) + 42)
|
|
|
|
|
|
|
|
|
2007-05-25 19:18:11 +04:00
|
|
|
int main(int argc, char **argv)
|
2001-07-04 22:04:58 +04:00
|
|
|
{
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
int i, j, size;
|
|
|
|
unsigned char testarray[12];
|
|
|
|
unsigned char *bigarray;
|
2001-07-04 22:04:58 +04:00
|
|
|
|
|
|
|
size = sizeof(bitarray)*8;
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
#if 0
|
2001-07-04 22:04:58 +04:00
|
|
|
i = ext2fs_find_first_bit_set(bitarray, size);
|
|
|
|
while (i < size) {
|
|
|
|
printf("Bit set: %d\n", i);
|
|
|
|
i = ext2fs_find_next_bit_set(bitarray, size, i+1);
|
|
|
|
}
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Test test_bit */
|
|
|
|
for (i=0,j=0; i < size; i++) {
|
|
|
|
if (ext2fs_test_bit(i, bitarray)) {
|
|
|
|
if (bits_list[j] == i) {
|
|
|
|
j++;
|
|
|
|
} else {
|
|
|
|
printf("Bit %d set, not expected\n", i);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (bits_list[j] == i) {
|
|
|
|
printf("Expected bit %d to be clear.\n", i);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf("ext2fs_test_bit appears to be correct\n");
|
|
|
|
|
|
|
|
/* Test ext2fs_set_bit */
|
|
|
|
memset(testarray, 0, sizeof(testarray));
|
|
|
|
for (i=0; bits_list[i] > 0; i++) {
|
|
|
|
ext2fs_set_bit(bits_list[i], testarray);
|
|
|
|
}
|
|
|
|
if (memcmp(testarray, bitarray, sizeof(testarray)) == 0) {
|
|
|
|
printf("ext2fs_set_bit test succeeded.\n");
|
|
|
|
} else {
|
|
|
|
printf("ext2fs_set_bit test failed.\n");
|
|
|
|
for (i=0; i < sizeof(testarray); i++) {
|
|
|
|
printf("%02x ", testarray[i]);
|
|
|
|
}
|
|
|
|
printf("\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
for (i=0; bits_list[i] > 0; i++) {
|
|
|
|
ext2fs_clear_bit(bits_list[i], testarray);
|
|
|
|
}
|
|
|
|
for (i=0; i < sizeof(testarray); i++) {
|
|
|
|
if (testarray[i]) {
|
|
|
|
printf("ext2fs_clear_bit failed, "
|
|
|
|
"testarray[%d] is %d\n", i, testarray[i]);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf("ext2fs_clear_bit test succeed.\n");
|
2008-08-28 07:07:54 +04:00
|
|
|
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
|
|
|
|
/* Do bigarray test */
|
|
|
|
bigarray = malloc(1 << 29);
|
|
|
|
if (!bigarray) {
|
|
|
|
fprintf(stderr, "Failed to allocate scratch memory!\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
bigarray[BIG_TEST_BIT >> 3] = 0;
|
|
|
|
|
|
|
|
ext2fs_set_bit(BIG_TEST_BIT, bigarray);
|
|
|
|
printf("big bit number (%u) test: %d, expected %d\n", BIG_TEST_BIT,
|
|
|
|
bigarray[BIG_TEST_BIT >> 3], (1 << (BIG_TEST_BIT & 7)));
|
|
|
|
if (bigarray[BIG_TEST_BIT >> 3] != (1 << (BIG_TEST_BIT & 7)))
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
ext2fs_clear_bit(BIG_TEST_BIT, bigarray);
|
2007-05-25 19:18:11 +04:00
|
|
|
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
printf("big bit number (%u) test: %d, expected 0\n", BIG_TEST_BIT,
|
2007-05-25 19:18:11 +04:00
|
|
|
bigarray[BIG_TEST_BIT >> 3]);
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
if (bigarray[BIG_TEST_BIT >> 3] != 0)
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
printf("ext2fs_set_bit big_test successful\n");
|
|
|
|
|
|
|
|
|
|
|
|
/* Now test ext2fs_fast_set_bit */
|
|
|
|
memset(testarray, 0, sizeof(testarray));
|
|
|
|
for (i=0; bits_list[i] > 0; i++) {
|
|
|
|
ext2fs_fast_set_bit(bits_list[i], testarray);
|
|
|
|
}
|
|
|
|
if (memcmp(testarray, bitarray, sizeof(testarray)) == 0) {
|
|
|
|
printf("ext2fs_fast_set_bit test succeeded.\n");
|
|
|
|
} else {
|
|
|
|
printf("ext2fs_fast_set_bit test failed.\n");
|
|
|
|
for (i=0; i < sizeof(testarray); i++) {
|
|
|
|
printf("%02x ", testarray[i]);
|
|
|
|
}
|
|
|
|
printf("\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
for (i=0; bits_list[i] > 0; i++) {
|
|
|
|
ext2fs_clear_bit(bits_list[i], testarray);
|
|
|
|
}
|
|
|
|
for (i=0; i < sizeof(testarray); i++) {
|
|
|
|
if (testarray[i]) {
|
|
|
|
printf("ext2fs_clear_bit failed, "
|
|
|
|
"testarray[%d] is %d\n", i, testarray[i]);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf("ext2fs_clear_bit test succeed.\n");
|
2008-08-28 07:07:54 +04:00
|
|
|
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
|
|
|
|
bigarray[BIG_TEST_BIT >> 3] = 0;
|
|
|
|
|
|
|
|
ext2fs_fast_set_bit(BIG_TEST_BIT, bigarray);
|
|
|
|
printf("big bit number (%u) test: %d, expected %d\n", BIG_TEST_BIT,
|
|
|
|
bigarray[BIG_TEST_BIT >> 3], (1 << (BIG_TEST_BIT & 7)));
|
|
|
|
if (bigarray[BIG_TEST_BIT >> 3] != (1 << (BIG_TEST_BIT & 7)))
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
ext2fs_fast_clear_bit(BIG_TEST_BIT, bigarray);
|
2007-05-25 19:18:11 +04:00
|
|
|
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
printf("big bit number (%u) test: %d, expected 0\n", BIG_TEST_BIT,
|
2007-05-25 19:18:11 +04:00
|
|
|
bigarray[BIG_TEST_BIT >> 3]);
|
Fix the i386 bitmap operations so they are 32-bit clean
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2006-03-25 21:42:45 +03:00
|
|
|
if (bigarray[BIG_TEST_BIT >> 3] != 0)
|
|
|
|
exit(1);
|
|
|
|
|
|
|
|
printf("ext2fs_fast_set_bit big_test successful\n");
|
|
|
|
|
|
|
|
exit(0);
|
2001-07-04 22:04:58 +04:00
|
|
|
}
|