/boot/a: 0 extents found
works properly, but
Filesystem type is: ef53
Filesystem cylinder groups is approximately 61
File size of a is 0 (0 blocks, blocksize 1024)
ext logical physical expected length flags
a: 1 extent found
yields 1 extent when it should be 0.
Fix this up by special-casing no extents returned in verbose
mode; skip printing the header for the columns too, since there
are no columns to print.
Also, in nonverbose mode we can set fm_extent_count to 0
so that FIEMAP will just query the extent count without gathering
details; clarify this with a comment.
Addresses-RedHat-Bugzilla: 653234
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
On 32-bit platforms where the file system block size is 8k or greater,
the calculation bpib*bpib*bpib* will overflow a 32-bit calculation,
leading to a divide by zero error. Fix this.
Thanks to Mikulas Patocka for pointing this out.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The extent list header gets printed before we fall back to bmap:
# filefrag -v /mnt/test/bar
Filesystem type is: 58465342
File size of /mnt/test/bar is 12288 (3 blocks, blocksize 4096)
ext logical physical expected length flags <---- HERE
Discontinuity: Block 2 is at 17 (was 16)
/mnt/test/bar: 2 extents found
so delay printing it until we know fiemap is working.
(though ideally it'd be nice to have the same verbose output
regardless of the interface we used, I think).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The fragmentation count in the bmap case seems to be
off by one:
/mnt/test/bar: 0 extents found
Addresses-Debian-Bug: #540376
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The FIEMAP support added in e2fsprogs 1.41.6 broke the "perfection
would be XXX expects" calculation restore it.
Also fix some gcc -Wall warnings as well. (Cleaning up gcc -Wall is
what caused me to notice this regression).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When used with -v and the targeted file has more than 144
extents(double of the length of fm_extents array provided by buf),
filefrag_fiemap loops and calls fiemap ioctl() multiple times to
calculate the actual number of extents in a file. Each call to fiemap
ioctl() uses fm_start as the starting logical offset. The patch fixes
fm_start in each loop( except for the first one) and makes the extent
calculation correct for files with more that 144 extents.
To produce the problem, first run filefrag -v on a highly fragmented
file. Then change the buf size in filefrag_fiemap to make it large
enough to have all the extent mapped in a single loop and run filefrag
-v after recompiling. The former will produce a much smaller extent
count because of the false fm_start used in the loop. And the two will
produce different extent output since the 145th extent.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The FIEMAP ioctl is more efficient and doesn't require root
privileges. So if it is available, use it in preference to repeated
FIBMAP calls.
Signed-off-by: Kalpak Shah <kalpak.shah@sun.com>
Signed-off-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Fix calculation of the ideal number of extents needed for a file to
take into account sparse files.
In addition, suppress the "this file is extent-based" message unless
verbose mode is enabled.
Addresses-Debian-Bug: #458306
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a new function, ext2fs_div_ceil(), which correctly calculates a division
of two unsigned integer where the result is always rounded up the next
largest integer. This is used everywhere where we might have
previously caused an overflow when the number of blocks
or inodes is too close to 2**32-1.
Based on patches from Eric Sandeen, but generalized to use this new function
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Eric Sandeen <esandeen@redhat.com>
This fixes some (but not all) of the compatibility bugs which prevented
e2fsprogs from being compiled on a Linux 2.0.35 system. There are still
some unprotected use of long long's, and apparently some type problems
with the uuid library, but these can be fixed up later.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Currently filefrag uses signed int for block numbers, thus it reporting
corrupted block number for a file on a more than 8TB ext3. The following
trivial patch replace the signed int type block number with "unsigned
long type.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
an integer, not an unsigned long. Fix this to avoid problems on 64-bit
platforms where the size of an integer != the size of a long.
(Addresses Debian Bug #309655)
stored using the new experimental file fragments format,
and use the non-ext2 algorithm for determing the number of
extents. Avoid reporting a false discontinuity if there
is a non-allocated block (or extent) at the beginning of
the file.
Theodore Ts'o