From: Tao Ma <tm@tao.ma>
To: Valdis.Kletnieks@vt.edu
Cc: Ted Ts'o <tytso@mit.edu>,
ext4 development <linux-ext4@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andreas Dilger <adilger@dilger.ca>
Subject: Re: [PATCH V1 00/17] ext4: Add inline data support.
Date: Thu, 27 Oct 2011 21:54:58 +0800 [thread overview]
Message-ID: <4EA962B2.3030402@tao.ma> (raw)
In-Reply-To: <7941.1319699422@turing-police.cc.vt.edu>
On 10/27/2011 03:10 PM, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 26 Oct 2011 15:32:24 +0800, Tao Ma said:
>
>> Currently I use all the space between i_extra_isize and inode_size if
>> inode_size = 256. For inode_size > 256, half of that space is used so as
>> to leave some space for other xattrs.
>
> I didn't check the code too closely - does this code DTRT if the user tries to
> then attach a moby-sized xattr (or set of xattrs - if it's got a security.selinux
> tag on it, and a security.capabilities xattr, and a user xattr or two, things are
> going to be getting full).
sure, it will work and all these stuff will be inserted to the external
xattr block since the in-inode space is full.
>
>> This is only a V1 and there are still something to do(e.g. I am thinking
>> of using unused extent space), but I'd like to send it out earlier so
>> that it can be reviewed ASAP.
>
> If this works out, would it make sense to investigate doing this for all
> tails in a V2? So if your file was 4099 bytes long, you could save allocating
> a second block. Assuming random distribution of tail sizes, this wil save
> an average of (space avail for tail)/(blocksize) per file.
uh, it seems like a good suggestion, but it will make the code a little
bit complicated(at least compared to the current version) and I am not
sure whether the maintainer like it or not ;) . So Ted and Andreas, What
do you think of this?
Thanks
Tao
prev parent reply other threads:[~2011-10-27 13:55 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
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 [this message]
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=4EA962B2.3030402@tao.ma \
--to=tm@tao.ma \
--cc=Valdis.Kletnieks@vt.edu \
--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 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.