On Sun, Sep 13, 2009 at 1:49 PM, SandeepKsinha <sandeepksinha@xxxxxxxxx> wrote: > On Sun, Sep 13, 2009 at 11:08 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >> On Sun, Sep 13, 2009 at 10:12 PM, SandeepKsinha <sandeepksinha@xxxxxxxxx> wrote: >>> Hi, >>> >>> >>> On Sun, Sep 13, 2009 at 10:07 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >>>> On Sun, Sep 13, 2009 at 5:44 PM, SandeepKsinha <sandeepksinha@xxxxxxxxx> wrote: >>>>> Hi all, >>>>> >>>>> Looking at the flags in the extent info, Is there any specifc flags >>>>> which indicates an extent to be a HOLE?? >>>> >>>> I am not sure if I understand the question correctly ...... why would >>>> you need that ? Can you give an example where it should be used ?? >>>> >>> >>> Look at e4defrag.c, >>> it checks the file size and allocates the same number of blocks for >>> donor inode. Which will eventually make a holey file into a normal >>> one. >>> Any tool/application should make sure that they leave a sparse file as sparse. >>> >>> I think, as suggested by Greg Freemyer, we can use BMAP ioctl to get >>> such information. >> >> Yes, but I think bmap would be costly if the file is large and is not >> holey :-( .... but that would be probably same calling fiemap if the >> file is completely fragmented such that each extent size is 1. >> > > Since, ext2/ext3 did not have mutli block allocation thats why this is > the only way that we might have. > But generally most of the new features work on with extent based files on ext4. > > I am still wondering that how to we represent a hole using extents in > a extent based file. > Just like we had a convention of having the block number 0 in case of holes. > > Similarly, what do we look at to figure out if its a hole or not. BMAP > is one way. But since, in a extent based file, we have only extents, > there should be some flag to indicate the same. Sandeep, If you look at e4defrag, it first gets a list of all the extents. I'm pretty sure extents only exist for allocated extents. Holes do not have any associated extents. Then it calls merge_extents to create extent groups. In e4defrag terminology, an extent group is a collection of all the logically contiguous extents. I don't know if the kernel uses that terminology or not. In other words in e4defrag terminology a sparse file is a series of: extent group - hole - extent group - hole - extent group - etc. Then e4defrag creates a donor file with exactly the same allocated block areas by calling fallocate on the donor file for each extent group with the same starting offset and length as the extent group. Thus the donor file ends up have exactly the same holes as the original file. Then the donor blocks are used to defrag the original file by calling move_extent. In the kernel, the move_extent logic looks for holes and only replaces blocks that are allocated in the original file. Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
