linux-ext4 - Re: [PATCH V1 00/17] ext4: Add inline data support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4EA7C1FD.3090907@tao.ma>
Date:	Wed, 26 Oct 2011 16:17:01 +0800
From:	Tao Ma <tm@....ma>
To:	Amir Goldstein <amir73il@...il.com>
CC:	Ted Ts'o <tytso@....edu>,
	ext4 development <linux-ext4@...r.kernel.org>,
	Andreas Dilger <adilger@...ger.ca>
Subject: Re: [PATCH V1 00/17] ext4: Add inline data support.

On 10/26/2011 04:05 PM, Amir Goldstein wrote:
> 
> 
> On Wed, Oct 26, 2011 at 9:32 AM, Tao Ma <tm@....ma <mailto:tm@....ma>>
> wrote:
> 
>     Hi Ted, Andreas and list,
>            This is my 1st attempt to add inline data support to ext4
>     inode. For
>     more information about the background, please refer to the thread
>     http://marc.info/?l=linux-ext4&m=131715205428067&w=2
>     <http://marc.info/?l=linux-ext4&m=131715205428067&w=2>
>     When I sent out the RFC on Sep.27, Andreas suggested that we can use the
>     space of xattr to put inline data. So this is the 1st version using that
>     method. It should be easy to change if we decide to use other places in
>     inode(e.g the unused extent space) since all the inline data
>     manipulation function is wrapped with function like ext4_*_inline_data.
> 
>     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.
> 
>     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.
> 
>     Some simple tests shows that with a linux-3.0 vanilla source, the new
>     dir can save 1% disk space. For my "/usr", it can save about 3.2%
>     spaces. I guess for volume with future bigalloc support, it should save
>     more space for us for small dir. I also run some other tests and it
>     seems the code is OK for a try. I haven't found a good test cases that
>     can test the small file/dir(tens of bytes in my case) performance where
>     inline data should have some good number.
> 
>     Any comments are welcomed.
> 
>     git diff --stat
> 
>     fs/ext4/dir.c    |  117 ++++++++++-
>     fs/ext4/ext4.h   |   15 +-
>     fs/ext4/ialloc.c |    4 +
>     fs/ext4/inode.c  |  583
>     +++++++++++++++++++++++++++++++++++++++++++++++---
> 
> 
> Hi Tao,
> 
> One generic comment.
> how about adding a new file fs/ext4/inline.c to host inline data support
> related code?
> inode.c is too big as it is and there is an effort the size it down.
sure, I will try to separate related functions to inline.c in my V2.

Thanks
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html