Thanks Eric. That explains. Donor file is out of the influence of delayed allocation. But now I wonder about target file which needs to be de-fragmented. Defrag sounds tricky if part of this file is on-disk (i.e. extent information is present) while remaining is yet to be written-back (i.e. extents are yet to be allocated). On Wed, Aug 29, 2018 at 10:20 PM Eric Sandeen <esandeen@xxxxxxxxxx> wrote: > > On 8/29/18 11:22 AM, Joshi wrote: > > Possibly a newbie question for the list, excuse my ignorance. > > I saw e4defrag code, which fallocates a temporary file in the outset. > > > > I imagine that extents would not get allocated to the this file at > > this time due to delayed-allocation feature (extent/block allocations > > should happen post writes which seem to happen much later, during > > extents copying between target-file and temporary-file). > > > > However, e4defrag needs extent information just after fallocate() to > > determine whether it is wise to go-ahead with defrag process i.e. > > whether new file is any less-fragmented than target one. I wonder how > > this decision-making is possible if fallocate does not allocate > > extents/blocks. > > > > I'd appreciate the thoughts. > > fallocate does not uses delayed allocation; it actually allocates > specific blocks on disk before it returns. So delayed allocation > doesn't come into play for the temporary/donor file. > > (delayed allocation happens during writeback, but for fallocate the > whole point is that there is no data written, it is simply an extent > allocation which is flagged to show that it is a preallocated extent > and that until it /is/ written to, reads should return 0s.) > > -Eric -- Joshi
