All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: Which features should I implement in my ext4 reader?
Date: Wed, 4 Sep 2013 13:35:03 +0800	[thread overview]
Message-ID: <20130904053503.GA3518@gmail.com> (raw)
In-Reply-To: <CACyNnZNQf6a05zE64KfouuT=dUXaNPT7iqPe8HKT1wXKz+pK0Q@mail.gmail.com>

On Mon, Sep 02, 2013 at 02:35:31PM +0200, Felipe Monteiro de Carvalho wrote:
> Hello,
> 
> Ok, I think I got it almost finished =) Just 1 last wierd thing. I
> dumped my inode and I found that when the extended attribute is in the
> space after the inode, then the attribute data starts 3 bytes before
> the end of this area! But in the wiki nothing is said about this. It
> was supposed to start at the end of the section ... not 3 bytes before
> the end of the section
> 
> Here are the 3 zeroes in the end:
> 
> 7760 4444 4444 4444 4444 4444 4444 0a00 0000 DDDDDDDDDDDD....
> 
> Any idea what are those 3 zeroes in the end? I simply hardcoded in my
> application that there exists 3 zeroes in the end, but its really
> strange as this does not make any sense to waste 3 bytes and I didn't
> see any such a thing in the wiki nor the xattr.h header...
> 
> Also wierd: This 3 last bytes do no appear when extended attributes
> are stored in a separate block.

Could you please tell me how to reproduce this problem?  I try to create
a file with inline data, but I couldn't reproduce your problem.

Thanks,
                                                - Zheng

> 
> Full set of dumps:
> 
> debugfs: stat smallfile120.txt
> Inode: 16 Type: regular Mode: 0644 Flags: 0x10000000
> Generation: 230499867 Version: 0x00000000:00000001
> User: 0 Group: 0 Size: 121
> File ACL: 0 Directory ACL: 0
> Links: 1 Blockcount: 0
> Fragment: Address: 0 Number: 0 Size: 0
>  ctime: 0x52149464:04e2df1c -- Wed Aug 21 06:20:20 2013
>  atime: 0x52177658:c0a4e548 -- Fri Aug 23 10:48:56 2013
>  mtime: 0x52149464:04e2df1c -- Wed Aug 21 06:20:20 2013
> crtime: 0x52149464:04e2df1c -- Wed Aug 21 06:20:20 2013
> Size of extra inode fields: 28
> Extended attributes stored in inode body:
>   data = "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD\012" (61)
> INLINE DATA:
>   The size of inline data: 121
> 
> More detailed information about the file with extended attribute:
> 
> debugfs: imap smallfile120.txt
> Inode 16 is part of block group 0
>         located at block 65, offset 0x0f00
> 
> So we know that it is located in the block 0000065 with offset 0x0f00
> = 0740 octal
> 
> debugfs: block_dump 65
> .....
> *
> 7400 a481 0000 7900 0000 5876 1752 6494 1452 ....y...Xv.Rd..R
> 7420 6494 1452 0000 0000 0000 0100 0000 0000 d..R............
> 7440 0000 0010 0100 0000 4141 4141 4141 4141 ........AAAAAAAA
> 7460 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
> 7500 4141 4141 4141 4242 4242 4242 4242 4242 AAAAAABBBBBBBBBB
> 7520 4242 4242 4242 4242 4242 4242 4242 4242 BBBBBBBBBBBBBBBB
> 7540 4242 4242 1b26 bd0d 0000 0000 0000 0000 BBBB.&..........
> 7560 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 7600 1c00 0000 1cdf e204 1cdf e204 48e5 a4c0 ............H...
> 7620 6494 1452 1cdf e204 0000 0000 0000 02ea d..R............
> 7640 0407 2000 0000 0000 3d00 0000 0000 0000 .. .....=.......
> 7660 6461 7461 0000 0000 0000 0000 0000 0000 data............
> 7700 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC
> 7720 4343 4343 4343 4343 4343 4343 4343 4444 CCCCCCCCCCCCCCDD
> 7740 4444 4444 4444 4444 4444 4444 4444 4444 DDDDDDDDDDDDDDDD
> 7760 4444 4444 4444 4444 4444 4444 0a00 0000 DDDDDDDDDDDD....
> 
> And thats how I got to this place.
> 
> thanks,
> 
> Felipe Monteiro de Carvalho
> 
> On Mon, Sep 2, 2013 at 2:07 PM, Zheng Liu <gnehzuil.liu@gmail.com> wrote:
> > Hello,
> >
> > Sorry for my late reply.
> >
> > On Mon, Sep 02, 2013 at 11:40:15AM +0200, Felipe Monteiro de Carvalho wrote:
> >> Hello,
> >>
> >> Ok, I found the extra data over 60 bytes ... it is in an extended
> >> attribute called "data" in the space after the inode. The wiki says it
> >> should be called "system.data" =(
> >>
> >> Also the wiki says here
> >> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes
> >> that "Extended attributes, when >>>not<<<< stored after the inode,
> >> have a header ext4_xattr_ibody_header that is 4 bytes long:"
> >>
> >> Which in my oppinion is false, it should be: "Extended attributes,
> >> when stored after the inode, have a header ext4_xattr_ibody_header
> >> that is 4 bytes long:"  without the "not"
> >>
> >> But I still am not sure of one thing: How can I know how many entries
> >> of extended attributes there are? Nothing in the wiki explains this =(
> >
> > You need to traverse the all entries to get this value.
> >
> >>
> >> Otherwise I cannot differentiate between yet another entry and simply
> >> data from an extended attribute...
> >
> > You can use attribute name and name index to differentiate these
> > entries.  You can read the comment at the front of fs/ext4/xattr.c and
> > it might help you to understand extended attribute.
> >
> > Regards,
> >                                                 - Zheng
> 
> 
> 
> -- 
> Felipe Monteiro de Carvalho
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-09-04  5:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12 15:38 Which features should I implement in my ext4 reader? Felipe Monteiro de Carvalho
2013-08-14  5:06 ` Felipe Monteiro de Carvalho
2013-08-17  6:27   ` Felipe Monteiro de Carvalho
2013-08-17 13:02   ` Theodore Ts'o
2013-08-18  6:04     ` Felipe Monteiro de Carvalho
2013-08-19  5:08       ` Zheng Liu
2013-08-20 10:16         ` Felipe Monteiro de Carvalho
2013-08-20 10:39           ` Zheng Liu
2013-08-21 12:16             ` Felipe Monteiro de Carvalho
2013-08-23 12:54               ` Felipe Monteiro de Carvalho
2013-08-28 20:09                 ` Felipe Monteiro de Carvalho
2013-09-02  9:40                   ` Felipe Monteiro de Carvalho
2013-09-02 12:07                     ` Zheng Liu
2013-09-02 12:35                       ` Felipe Monteiro de Carvalho
2013-09-04  5:35                         ` Zheng Liu [this message]
2013-09-05  5:25                           ` jon ernst
     [not found]                           ` <CAGW2f1FgHZsQbNMyWiD997UZz55y20qHJHryEcMsgpEwecxftA@mail.gmail.com>
2013-09-05  7:04                             ` Felipe Monteiro de Carvalho
2013-09-05  7:41                               ` Felipe Monteiro de Carvalho
2013-09-02 16:41                     ` Darrick J. Wong
2013-08-19 14:03       ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130904053503.GA3518@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=felipemonteiro.carvalho@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.