linux-ext4 - Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

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>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 20 Apr 2010 17:40:41 +0900
From:	Kazuya Mio <k-mio@...jp.nec.com>
To:	Greg Freemyer <greg.freemyer@...il.com>
CC:	ext4 <linux-ext4@...r.kernel.org>, Theodore Tso <tytso@....edu>,
	linux-fsdevel@...r.kernel.org, ohsm-devel@...ts.sourceforge.net,
	dmonakhov@...nvz.org
Subject: Re: [RFC][PATCH 0/3] ext4: inode preferred block allocation

2010/04/16 1:22, Greg Freemyer wrote:
> I have a basic understanding how these could be used by e4defrag to
> organize stable data blocks / extents, but is the goal to also allow a
> working set of dynamic files which allocate new data blocks routinely?
> 
> == details / example
> 
> Assume I know that files owned by a specific user (such as the apache
> daemon) need to be collocated to reduce seek times as pages are
> displayed.
> 
> After the fact, I can see the e4defrag moving all files with UID
> apached into a subset of block groups thus increasing locality and
> decreasing seeks.
> 
> But what if those files themselves are dynamically being created /
> extended and thus allocating new data blocks/extents on the fly.   The
> need in that situation would be more along the lines of defining a
> preferred block group range for all files with the same UID.  And all
> of those files would be provided exactly the same block range.

Even if we implement preferred block group range, the problem you said will
occur. Because we don't know how much data will be increased.
If you really want the function, you will be able to materialize your idea by
creating the persistent inode preallocation in struct ext4_sb_info.

I don't have a plan to develop the function of the inode preferred range at
present. This patch has a function enough to realize new feature of e4derag.
Moreover, Andreas said we should not create a second similar mechanism.
http://marc.info/?l=linux-ext4&m=124650093015617&w=4

Best Regards,
Kazuya Mio
--
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