Hi Greg, Thanks a lot for such nice explanation. But I still have the same query lingering... On Mon, Sep 14, 2009 at 9:36 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > 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. > This is what my actual question is, think of this situation... |-------------|-------------|-------------|------------------| 0 500 700 1200 3000 [Logical block numbers for an inode] In this situation you will have four extents for sure. ext_1 -> 0 -- 500 ext_2 -> 501 --700 [ This will be an initialized extent] ext_3 -> 701 -- 1200 ext_4 -> 1200 -- 3000 After looking at the sources and some comments in the ext4 source code, I could figure out that holes would be having an initialized extent. Reference: http://lxr.linux.no/#linux+v2.6.31/fs/ext4/extents.c#L2843 I think we cannot have a mixture of both a BMAP and an EMAP, it will be either. > 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. > Hope they are not merging together any initialized and uninitialized extents together, since they can be logically contiguous. Or rather they will be. > 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. > This is true and should be applicable to initialized extents as well. I fear if they are > 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. > This is true. I am sure of the kernel logic. > Greg > -- Regards, Sandeep. “To learn is to change. Education is a process that changes the learner.” -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
