Hide Forgot
Created attachment 483711 [details] proposed fix I've sent this to Ted last month, but have heard nothing. So I'm logging here as I'll forget. Before: $ truncate -s 1G file $ filefrag -v file Filesystem type is: ef53 File size of file is 1073741824 (262144 blocks, blocksize 4096) ext logical physical expected length flags file: 1 extent found After: Filesystem type is: ef53 File size of file is 1073741824 (262144 blocks, blocksize 4096) file: 0 extents found
Thanks, I'll pester Ted too... did you send it to the list? I don't see anything from you ... however, this patch on the list last year, also not yet merged: [PATCH] filefrag: count optimize non-verbose mode; count 0 extents properly when verbose fixes it as well, I think... I pinged Ted.
I did not send it to linux-ext4.org as there was no mention of that list in the e2fsprogs package. Thanks for reviving this.
Patch respun, sent, and pinged again.
Ok, this did finally make it upstream. However, it is still not in any released e2fsprogs. Are you ok with this being closed UPSTREAM or do you really want/need it in a fedora release? Thanks, -Eric commit a8d8432b584c222dc7960c15cd7b9acbc7c72352 Author: Eric Sandeen <sandeen> Date: Thu May 5 13:21:08 2011 -0500 filefrag: count 0 extents properly when verbose /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> Signed-off-by: Theodore Ts'o <tytso>
Thanks for following this up Eric. I've marked this closed upstream, as there was no direct logic dependent on it. It just confused me when I was testing coreutils cp.