* [Bug 968876] e4defrag incorrectly calculates optimum extents
@ 2013-05-30 18:19 Joseph D. Wagner
0 siblings, 0 replies; only message in thread
From: Joseph D. Wagner @ 2013-05-30 18:19 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.redhat.com/show_bug.cgi?id=968876
The "Total/best extents" calculation for done in the e4defrag program
doesn't seems to not consider the limit of 32768 file system blocks (see
/usr/src/linux/fs/ext4/ext4_extents.h comment EXT_INIT_MAX_LEN) in an
extent when computing the "best" value. It seems to presume 2G is the
best extent size, but on a file system with a 4kb block size the largest
available extent is 128M not 2G.
(The best extent size calculation in e4defrag seems to be based on
block group size but the underlying implementation in the kernel is
limited to a __le16 blocks and uses up one whole bit of that to flag
whether the extent is initialized, which actually produces a one-block
perturbation in the actual limit based on how the extent was allocated
(e.g. whether falloc used FS_KEEP_SIZE or not), go go gadget perturbed
math. 8-)).
Example:
-rw-r--r-- 1 rwhite rwhite 5.0G Jun 13 16:28 CentOS.qcow2
yeilds output: (where "/3" is wrong).
Total/best extents 152/3
Proposed patch available here:
http://pastebin.com/9XTFcVM0
Joseph D. Wagner
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2013-05-30 19:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-30 18:19 [Bug 968876] e4defrag incorrectly calculates optimum extents Joseph D. Wagner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.