History log of /external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e0ed7404719a9ddd2ba427a80db5365c8bad18c0 20-Mar-2014 JP Abgrall <jpa@google.com> Switch back to 1.42.9 now that there is a fix

Revert "Revert changes that moved from 1.41.14 to 1.42.9"

This reverts commit 65f0aab98b20b5994a726ab90d355248bcddfffd.
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
65f0aab98b20b5994a726ab90d355248bcddfffd 06-Mar-2014 JP Abgrall <jpa@google.com> Revert changes that moved from 1.41.14 to 1.42.9

Revert "e2fsck: Don't use e2fsck_global_ctx unless HAVE_SIGNAL_H"
commit e80e74c41d85ff93f3d212ba6512340f48054a93.

Revert "Merge remote-tracking branch 'linaro/linaro-1.42.9' into aosp_master"
This reverts commit e97b2b6fc82f840e84dfc631b87f21be44ff2421, reversing
changes made to 7e2fb9d09c245eba70ee008b78007315e9c0f1df.

Revert "Prepare for upstream 1.42.9"
This reverts commit 7e2fb9d09c245eba70ee008b78007315e9c0f1df.

Bug: 13340735
Change-Id: If48b153a95ef5f69f7cdccb00e23524abff3c5a8
Signed-off-by: JP Abgrall <jpa@google.com>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
18a1444b4f1e6a0948fd38fa0de382d86cfe04de 31-Dec-2013 Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org> Add files that would normally be generated by the e2fsprogs build system

Android doesn't run ./configure and friends, so it has to rely on
pre-populated versions of the autogenerated files.

This is somewhat bogus (e.g. hardcoded little-endian reference in
lib/ext2fs/ext2_types.h) and should at some point be fixed, but it's
what Android has always done, not a regression from the 1.41.14 branch.

Also, don't #include config.h which we don't generate (we pass what it
usually contains as -D parameters from Android.mk) anywhere.

Add a new Android.mk file for the quota library.

Change-Id: I162c6327fee5bd06261d9cdcc34bda10f04a6f21
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
6a26b38ac46a0489bd477832dcaebd276c2f489b 11-Dec-2013 Darrick J. Wong <darrick.wong@oracle.com> libext2fs: fix memory leaks (on error paths)

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
e48bf256e99e4923c6193ff78000af18c700d93d 20-May-2013 Theodore Ts'o <tytso@mit.edu> libext2fs: fix gcc -Wall warnings

Primarily signed vs unsigned and const warnings.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
0d89e5acea99fc00d9b834eab6d228c47a71920a 28-Jan-2013 Philipp Thomas <pth@suse.de> Fix warnings about functions not returning a value

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
3e1816b8cc9086354453bd75aaaeade558f98b3e 20-Jan-2013 Theodore Ts'o <tytso@mit.edu> libext2fs: teach the ext2fs_*_block_bitmap_range2() about clusters

The ext2fs_{mark,unmark,test}_block_bitmap2() functions understand
about clusters, and will take block numbers and convert them to
clusters before checking the bitmap. The
ext2fs_*_block_bitmap_range2() functions did not do this, which made
them inconsistent. Fortunately, nothing has depended on this
incorrect behavior, and in fact most of the usage of these functions
have only recently been added, and only for optimizations that were
only enabled for non-bigalloc file systems.

So this is a change in previously exported functions, but (a) it
doesn't change the behavior at all for non-bigalloc file systems, and
(b) the change is more likely to fix bugs for bigalloc file systems.
For example, this change fixes a problem with resize2fs and bigalloc
file systems.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
664c332612a0ef86df5c67286155ea895ed88ee3 06-Apr-2012 Theodore Ts'o <tytso@mit.edu> libext2fs: add 32-bit compat code for ext2fs_find_first_zero_generic_bmap()

The lack of 32-bit support was causing febootstrap to crash since it
wasn't passing EXT2_FLAG_64BITS when opening the file system, so we
were still using the legacy bitmaps.

Also add support for bigalloc bitmap into the ffz functions.

Addresses-Red-Hat-Bugzilla: #808421

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
e64e6761aa22f31123a91206a5686526f7b9c6c0 05-Apr-2012 Theodore Ts'o <tytso@mit.edu> Fix gcc -Wall nitpicks

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
c1a1e7fc24d6e37f931bbb8eeb29c90243f0a55d 10-Mar-2012 Sami Liedes <sami.liedes@iki.fi> libext2fs: Implement ext2fs_find_first_zero_generic_bmap().

This function searches a bitmap for the first zero bit within a range.
It checks if there is a bitmap backend specific implementation
available (if the relevant field in bitmap_ops is non-NULL). If not,
it uses a generic and slow method by repeatedly calling test_bmap() in
a loop. Also change ext2fs_new_inode() to use this new function.

This change in itself does not result in a large speedup, rather it
refactors the code in preparation for the introduction of a faster
find_first_zero() for bitarray based bitmaps.

Signed-off-by: Sami Liedes <sami.liedes@iki.fi>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
b96365f8c2e48b714332d038c6360f9993ac17e0 27-Feb-2012 Mike Frysinger <vapier@gentoo.org> libext2fs: include sys/time.h for gettimeofday()

Building on my glibc-2.15 system hits a warning:
gen_bitmap64.c: In function 'ext2fs_alloc_generic_bmap':
gen_bitmap64.c:127:2: warning: implicit declaration of function
'gettimeofday' [-Wimplicit-function-declaration]

Include sys/time.h if it's available for the prototype.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
9288e3be665bb8d5657d7f710687a50fad859acf 16-Dec-2011 Lukas Czerner <lczerner@redhat.com> libext2fs: add bitmap statistics

This feature is especially useful for better understanding how e2fsprogs
tools (mainly e2fsck) treats bitmaps and what bitmap backend can be most
suitable for particular bitmap. Backend itself (if implemented) can
provide statistics of its own as well.

[ Changed to provide basic statistics when enabled with the
E2FSPROGS_BITMAPS_STATS environment variable -- tytso]

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
4a61d17c7c4c09ce3bb5f77bdb9b90eb9f10e8c3 17-Dec-2011 Theodore Ts'o <tytso@mit.edu> libext2fs: adjust the description when copying a bitmap

Label the copy of a bitmap as "copy of ..." so that the bitmap's
description is more descriptive.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
d182831a15dfa4d36979be10fdfd4ec06bdd65b9 18-Dec-2011 Theodore Ts'o <tytso@mit.edu> libext2fs: add pseudo bitmap backend type EXT2FS_BMAP64_AUTODIR

This backend type will automatically switch between the bitarray and
the rbtree backend based on the number of directories in the file
system.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
c1359d91958cadfbc0987921ee5b4db717852e90 18-Dec-2011 Lukas Czerner <lczerner@redhat.com> libext2fs: add a bitmap implementation using rbtree's

For a long time we had a bitarray backend for storing filesystem
metadata bitmaps, however today this approach might hit its limits with
todays huge data storage devices, because of its memory utilization.

Bitarrays stores bitmaps as ..well, as bitmaps. But this is in most
cases highly unefficient because we need to allocate memory even for the
big parts of bitmaps we will never use, resulting in high memory
utilization especially for huge filesystem, when bitmaps might occupy
gigabytes of space.

This commit adds another backend to store bitmaps. It is based on
rbtrees and it stores just used extents of bitmaps. It means that it can
be more memory efficient in most cases.

I have done some limited benchmarking and it shows that rbtree backend
consumes approx 65% less memory that bitarray on 312GB filesystem aged
with Impression (default config). This number may grow significantly
with the filesystem size, but also it may be a lot lower (even negative)
if the inodes are very fragmented (need more benchmarking).

This commit itself does not enable the use of rbtree backend.

[ Simplified the code by avoiding unneeded memory allocation and
deallocation of del_ext. In addition, fixed a bug discovered by the
tst_bitmaps tests: rb_unamrk_bmap() must return true if the bit was
previously set in bitmap, and zero otherwise -- tytso ]

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
67861e5bf3ae177b14d34846218fcdfdeee805a6 16-Dec-2011 Theodore Ts'o <tytso@mit.edu> libext2fs: add default_bitmap_type to the ext2_filsys structure

This allows a program to control the bitmap backend implementation
that will get used without needing to change the current library API.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
ba37bb704f4ab2631a39c32b35d6bb339e17b293 05-Dec-2011 Theodore Ts'o <tytso@mit.edu> libext2fs: don't break when ext2fs_clear_generic_bmap() for 32-bit bitmaps

This is only an issue for programs compiled against e2fsprogs 1.41
that manipulate bitmaps directly. Fortunately there are very few
programs which do that, especially those that try to clear a bitmap.

Addresses-Sourceforge-Bugs: #3451486

Reported-by: robi6@users.sourceforge.net
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
d1154eb460efe588eaed3d439c1caaca149fa362 18-Sep-2011 Theodore Ts'o <tytso@mit.edu> Shorten compile commands run by the build system

The DEFS line in MCONFIG had gotten so long that it exceeded 4k, and
this was starting to cause some tools heartburn. It also made "make
V=1" almost useless, since trying to following the individual commands
run by make was lost in the noise of all of the defines.

So fix this by putting the configure-generated defines in lib/config.h
and the directory pathnames to lib/dirpaths.h.

In addition, clean up some vestigal defines in configure.in and in the
Makefiles to further shorten the cc command lines.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
15749d7da9b6242d477801a54164b3d04c2b4102 16-Sep-2011 Amir Goldstein <amir73il@users.sf.net> libext2fs: fix the range validation in bitmap_range2 funcs

The condition ((start+num) & ~0xffffffffULL) in bitmap_range2
and generic_bmap_range funcs in get_bitmap64.c was wrong and
inconsistent with the condition (start+num-1 > bmap->real_end)
in generic_bitmap_range funcs in get_bitmap.c.

I got the following error from tune2fs on a 16TB fs:
Illegal block number passed to ext2fs_unmark_block_bitmap #4294967295
for block bitmap for 16TB.img
tune2fs: Invalid argument while reading bitmaps

Fix to condition to ((start+num-1) & ~0xffffffffULL), because
the bit (start+num) is not going to be changed by the funcs.

Signed-off-by: Amir Goldstein <amir73il@users.sf.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
9c79612f2186a8ee5d8a6f2c961e4e0f63df7228 10-Aug-2011 Eric Sandeen <sandeen@redhat.com> libext2fs: copy cluster_bits in ext2fs_copy_generic_bmap

The f_lotsbad regression test was failing on some systems
with:

Restarting e2fsck from the beginning...
Pass 1: Checking inodes, blocks, and sizes
+Illegal block number passed to ext2fs_test_block_bitmap #0 for in-use block map
Pass 2: Checking directory structure
Entry 'termcap' in / (2) has deleted/unused inode 12. Clear? yes

Running with valgrind (./test_script --valgrind f_lotsbad) we
see:

+==31409== Conditional jump or move depends on uninitialised value(s)
+==31409== at 0x42927A: ext2fs_test_generic_bmap (gen_bitmap64.c:378)

among others.

Looking at gen_bitmap64.c:
376: arg >>= bitmap->cluster_bits;
377:
378: if ((arg < bitmap->start) || (arg > bitmap->end)) {

A little more debugging showed that it was actually
bitmap->cluster_bits which was uninitialized, because it never
gets copied over in ext2fs_copy_generic_bmap()

Patch below resolves the issue.

Reported-by: Andreas Dilger <adilger@whamcloud.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
65d05cec3d4ae02dec1b15dfec21e571cb83c9cf 11-Jun-2011 Andreas Dilger <adilger@whamcloud.com> ext2fs: fix ext2fs_warn_bitmap32() return warning

This was reported as "control reaches end of non-void function",
but comparing to other similar functions it should be a void
function. Since it is only declared in the "private" ext2fsP.h
header, it should be OK to change the function prototype.

Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
94968e749b224f01fbb9009ed0285e55f6441784 10-Jun-2011 Theodore Ts'o <tytso@mit.edu> libext2fs: teach bitmap functions about bigalloc/cluster

This patch makes the following changes:

* ext2fs_allocate_block_bitmap() now allocates a bitmap with cluster
granularity for bigalloc file systems. For mke2fs and e2fsck, a
newly added function, ext2fs_allocate_subcluster_bitmap() allocates
a bitmap with block granularity (even for bigalloc file systems).
The newly added function ext2fs_get_bitmap_granularity() will return
the number of bits (log2) of the granularity used by the bitmap.

* The ext2fs_{mark,unmark,test}_block_bitmap2() functions will shift
their passed-in argument by log2(cluster_ganularity) bits right.
This means that the arguments for the single-argument bitmap
functions will be interpreted with block granluarity, since this
minimizes code changes in the rest of the code base.

* The ext2fs_{get,set}_block_bitmap_range() functions will interpret
their arguments in cluster granularity. This is a bit inconsistent,
but the caller of those functions will need to be taught about the
subtleties of clusters for bigalloc file systems.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
5fff975431e02c2b746b023d3c5e6755e910eaa9 21-Mar-2011 Lukas Czerner <lczerner@redhat.com> e2fsprogs: fix memory leak in ext2fs_free_generic_bmap()

In ext2fs_free_generic_bmap() when we are freeing 64-bit bitmap, we do
call free_bmap() to free backend specific bitmap structures, however we
should also free ext2fs_generic_bitmap structure as well.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
ba7cb5d9d7a9415ccb611e781a3832be7259622f 21-Mar-2011 Lukas Czerner <lczerner@redhat.com> e2fsprogs: fix freeing bitmap in allocation error path

In ext2fs_alloc_generic_bmap() error path, when new bitmap allocation
fails ext2fs_generic_bitmap should be freed, however in current state it
first frees ext2fs_generic_bitmap and then
ext2fs_generic_bitmap->description which is wrong. This commit fix the
free ordering.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
877d1dc0ab643086bf2eafcde7d0ce2478c036ee 29-Nov-2010 Namhyung Kim <namhyung@gmail.com> libext2fs: remove unnecessary casts to ext2fs_generic_bitmap

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
c21cde9986e69756254b65b7a48974222f358a2e 31-Jan-2010 Theodore Ts'o <tytso@mit.edu> libext2fs: Add some fail-safe checks to the 32-bit bitmap code

If a 64-bit bitmap is passed to a 32-bit bitmap function, add some
checks to make sure that we print a useful error message so we can
better catch potential problems.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c
69365c689b7164014e539b40ef62fc8eb804a05c 22-Aug-2009 Theodore Ts'o <tytso@mit.edu> Add support for 64-bit bitmaps

Initial design was done by Theodore Ts'o; implementation was fleshed
out by Valerie Aurora Henson. Also includes some fixes from Nick Dokos.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Valerie Aurora Henson <vaurora@redhat.com>
Signed-off-by: Nick Dokos <nicholas.dokos@hp.com>
/external/e2fsprogs/lib/ext2fs/gen_bitmap64.c