Jeff Liu wrote: > On 11/29/2012 12:15 PM, Jim Meyering wrote: >> Hugh Dickins wrote: >>> On Thu, 29 Nov 2012, Jaegeuk Hanse wrote: >> ... >>>> But this time in which scenario will use it? >>> >>> I was not very convinced by the grep argument from Jim and Paul: >>> that seemed to be grep holding on to a no-arbitrary-limits dogma, >>> at the expense of its users, causing an absurd line-length issue, >>> which use of SEEK_DATA happens to avoid in some cases. >>> >>> The cp of sparse files from Jeff and Dave was more convincing; >>> but I still didn't see why little old tmpfs needed to be ahead >>> of the pack. >>> >>> But at LinuxCon/Plumbers in San Diego in August, a more convincing >>> case was made: I was hoping you would not ask, because I did not take >>> notes, and cannot pass on the details - was it rpm building on tmpfs? >>> I was convinced enough to promise support on tmpfs when support on >>> ext4 goes in. >> >> Re the cp-vs-sparse-file case, the current FIEMAP-based code in GNU >> cp is ugly and complicated enough that until recently it harbored a >> hard-to-reproduce data-corrupting bug[*]. Now that SEEK_DATA/SEEK_HOLE >> support work will work also for tmpfs and ext4, we can plan to remove >> the FIEMAP-based code in favor of a simpler SEEK_DATA/SEEK_HOLE-based >> implementation. > How do we teach du(1) to aware of the real disk footprint with Btrfs > clone or OCFS2 reflinked files if we remove the FIEMAP-based code? > > How about if we still keep it there, and introduce SEEK_DATA/SEEK_HOLE > code to the extent-scan module which is dedicated to deal with sparse files? Hi Jeff, By "removing the FIEMAP-based code" I mean the uses in copy.c. All of that should remain independent of how du does its job, so if FIEMAP is required for your planned du enhancement, then feel free to use it. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>