On Mon, Sep 14, 2009 at 11:59 AM, SandeepKsinha <sandeepksinha@xxxxxxxxx> wrote: > 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. I did a extent dump of a holey file. Inode: 12 Type: regular Mode: 0644 Flags: 0x80000 Generation: 4284390079 Version: 0x00000001 User: 5572 Group: 5573 Size: 20877312000 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 16000 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x4aae0975 -- Mon Sep 14 14:44:29 2009 atime: 0x4aad34e9 -- Sun Sep 13 23:37:37 2009 mtime: 0x4aae0975 -- Mon Sep 14 14:44:29 2009 EXTENTS: (0-3999): 10241-14240, (20384000-20387999): 14337-18336 Level Entries Logical Physical Length Flags 0/ 0 1/ 2 0 - 3999 10241 - 14240 4000 0/ 0 2/ 2 20384000 - 20387999 14337 - 18336 4000 I am looking at the source, but as you can see it is not printing the extents for the hole part. >> > > 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.” > -- Thanks - Manish -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
