linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tao Ma <tm@tao.ma>
To: Andreas Dilger <adilger@dilger.ca>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V1 02/17] ext4: Add the basic function for inline data support.
Date: Wed, 26 Oct 2011 22:38:08 +0800	[thread overview]
Message-ID: <4EA81B50.1060802@tao.ma> (raw)
In-Reply-To: <E38E92E9-2937-47BA-A9F4-B1F75C9FDE4A@dilger.ca>

On 10/26/2011 04:36 PM, Andreas Dilger wrote:
> On 2011-10-26, at 1:34 AM, Tao Ma wrote:
>> Implement inline data with xattr. This idea is inspired by Andreas.
>> So now we use "system.data" to store xattr.  For inode_size = 256,
>> currently we uses all the space between i_extra_isize and inode_size.
>> For inode_size > 256, we use half of that space.
>>
>> +#define EXT4_XATTR_SYSTEM_DATA_NAME		"data"
> 
> Did you check whether the "data" string takes 4 bytes or 8 in the
> xattr header?  I believe it is storing the NUL termination (and
> the code is using "sizeof(EXT4_XATTR_SYSTEM_DATA_NAME)" = 5), so
> I believe it will round up to the next 4-byte boundary.  Using a
> 3-byte name will save a bit of space, like "system.dat".
Actually it will takes 4 bytes instead of 8, since in
ext4_xattr_set_entry it uses memcpy to copy the name with namelen
initialized with strlen("data"). So "data" is fine here. As for the
calculation of max_inline_size, yes, it uses
sizeof(EXT4_XATTR_SYSTEM_DATA_NAME) which should be changed to strlen.
Thanks for the advice.
> 
>> +void ext4_write_inline_data(struct inode *inode, struct ext4_iloc *iloc,
>> +			    void *buffer, loff_t pos, unsigned len)
>> +{
>> +	header = IHDR(inode, ext4_raw_inode(iloc));
>> +	entry = (struct ext4_xattr_entry *)((void *)ext4_raw_inode(iloc) +
>> +					    EXT4_I(inode)->i_inline_off);
>> +	memcpy((void *)IFIRST(header) + le16_to_cpu(entry->e_value_offs) + pos,
>> +	       buffer + pos, len);
>> +}
>> +
>> +int ext4_init_inline_data(handle_t *handle, struct inode *inode,
>> +			  struct ext4_iloc *iloc)
>> +{
>> +	size = ext4_get_max_inline_size(inode);
>> +	value = kzalloc(size, GFP_NOFS);
>> +	if (!value)
>> +		return -ENOMEM;
>> +
>> +	error = ext4_xattr_ibody_set(handle, inode, &i, &is);
>> +}
> 
> Since file data is changed very rarely, instead of consuming the full
> xattr space that may not be needed, wouldn't it be better to change
> ext4_write_inline_data() to just to the ext4_xattr_ibody_set() to save
> the exact-sized buffer into the xattr?  That will allow other xattrs
> to be stored in this space as well as the inline data.
I am just worried about the cpu usage. You know, the xattr values in
ext4 has to be packed so if we change the content of an inline file
frequently(say append), the inline xattr value will be removed and added
frequently which should consume much cpu cycles. What's more, the other
xattr values has to be moved also if they are not aligned to the end of
the inode. I am not sure whether it is good for performance or not.
Another side effect is that we have to write the whole inline data every
time as a new xattr value replace every time while the current solution
just needs to memcpy the appended bytes.

Thanks
Tao

  reply	other threads:[~2011-10-26 14:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-26  7:32 [PATCH V1 00/17] ext4: Add inline data support Tao Ma
2011-10-26  7:34 ` [PATCH V1 01/17] ext4: Move extra inode read to a new function Tao Ma
2011-10-26  7:34   ` [PATCH V1 02/17] ext4: Add the basic function for inline data support Tao Ma
2011-10-26  8:36     ` Andreas Dilger
2011-10-26 14:38       ` Tao Ma [this message]
2011-10-26 22:28         ` Andreas Dilger
2011-10-27  0:51           ` Tao Ma
2011-10-27  0:51           ` Tao Ma
2011-10-27  9:57             ` Andreas Dilger
2011-10-27 14:53               ` Tao Ma
2011-11-02 21:16                 ` Andreas Dilger
2011-11-03  4:23                   ` Tao Ma
2011-10-26  7:34   ` [PATCH V1 03/17] ext4: Add read support for inline data Tao Ma
2011-10-26  7:34   ` [PATCH V1 04/17] ext4: Add normal write " Tao Ma
2011-10-26  7:34   ` [PATCH V1 05/17] ext4: Add journalled " Tao Ma
2011-10-26  7:34   ` [PATCH V1 06/17] ext4: Add delalloc " Tao Ma
2011-10-26  7:34   ` [PATCH V1 07/17] ext4: Create a new function ext4_init_new_dir Tao Ma
2011-10-26  7:34   ` [PATCH V1 08/17] ext4: Refactor __ext4_check_dir_entry to accepts start and size Tao Ma
2011-10-26  7:34   ` [PATCH V1 09/17] ext4: Create __ext4_insert_dentry for dir entry insertion Tao Ma
2011-10-26  7:34   ` [PATCH V1 10/17] ext4: let add_dir_entry handle inline data properly Tao Ma
2011-10-26  7:34   ` [PATCH V1 11/17] ext4: Let ext4_readdir handle inline data Tao Ma
2011-10-26  7:34   ` [PATCH V1 12/17] ext4: Create a new function search_dir Tao Ma
2011-10-26  7:34   ` [PATCH V1 13/17] ext4: let ext4_find_entry handle inline data Tao Ma
2011-10-26  7:34   ` [PATCH V1 14/17] ext4: let ext4_delete_entry " Tao Ma
2011-10-26  7:34   ` [PATCH V1 15/17] ext4: let empty_dir handle inline dir Tao Ma
2011-10-26  7:34   ` [PATCH V1 16/17] ext4: let ext4_rename " Tao Ma
2011-10-26  7:34   ` [PATCH V1 17/17] ext4: Enable ext4 inline support Tao Ma
     [not found] ` <CAOQ4uxgpkd5WwwwkuxTupYRS-2Nf7mu=V5JCO2CTYQN3k0BCCg@mail.gmail.com>
2011-10-26  8:17   ` [PATCH V1 00/17] ext4: Add inline data support Tao Ma
2011-10-27  7:10 ` Valdis.Kletnieks
2011-10-27 13:54   ` Tao Ma

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=4EA81B50.1060802@tao.ma \
    --to=tm@tao.ma \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).