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. With the rise of virtualization, copying sparse images efficiently (probably searching, too) is becoming more and more important. So, yes, GNU cp will soon use this feature. [*] https://plus.google.com/u/0/114228401647637059102/posts/FDV3JEaYsKD -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
