linux-ext4 - Re: [RFC][Patch 2/2] Persistent preallocation in ext4

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

Message-ID: <20061222151615.GA5851@amitarora.in.ibm.com>
Date:	Fri, 22 Dec 2006 20:46:15 +0530
From:	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	linux-ext4@...r.kernel.org, suparna@...ibm.com, cmm@...ibm.com,
	suzuki@...ibm.com, alex@...sterfs.com
Subject: Re: [RFC][Patch 2/2] Persistent preallocation in ext4

On Tue, Dec 19, 2006 at 02:14:09PM -0700, Andreas Dilger wrote:
> On Dec 19, 2006  17:12 +0530, Amit K. Arora wrote:
> > I wrote a simple tool to test these patches. The tool takes four
> > arguments:
> >
> > * command: It may have either of the two values - "prealloc" or "write"
> > * filename: This is the filename with relative path
> > * offset: The offset within the file from where the preallocation, or
> > 		the write should start.
> > * length: Total number of bytes to be allocated/written from offset.
> >
> > Following cases were tested :
> > 1. * preallocation from 0 to 32MB
> >    * write to various parts of the preallocated space in sets
> >    * observed that the extents get split and also get merged
> >
> > 2. * preallocate with holes at various places in the file
> >    * write to blocks starting from a hole and ending into preallocated
> >       blocks and vice-versa
> >    * try to write to entire set of blocks (i.e. from 0 to the last
> >       preallocated block) which has holes in between.

Hi Andreas,

> An ideal test would be to modify fsx to (randomly) do preallocations
> instead of truncates that increase the size.
Thanks for the suggestion. The modified fsx (used "fsx-linux" in LTP as
the base) did uncover couple of bugs. One has a straight forward fix of
using ext4_ext_get_actual_len() in ext4_ext_put_gap_in_cache(). Without
this change, it is resulting in a panic when a ftruncate() of size zero
is done on an extent enabled file with preallocated blocks.

The other problem is slightly more complicated and occurs in some
specific conditions (filesize >= 512KB and number of operations >=
100000). When it happens, it results in duplicate entries for a few
logical block numbers in the tree. It looks as if some kind of "leak" is
happening while splitting/merging extents. Following is a typical
example (this is an output from debugfs in e2fsprogs-1.39 utils, which
has the patch supporting preallocation applied to it):

debugfs 1.39 (29-May-2006)
debugfs:  stat testfile
header: magic=f30a entries=1 max=4 depth=1 generation=0
index: block=0 leaf=1201 leaf_hi=0 unused=0
header: magic=f30a entries=16 max=84 depth=0 generation=0
extent[u]: block=0-25 len=26 start=645 start_hi=0
extent[i]: block=26-67 len=42 start=671 start_hi=0
extent[u]: block=68-502 len=435 start=713 start_hi=0
extent[i]: block=76-107 len=32 start=589 start_hi=0
extent[i]: block=116-131 len=16 start=629 start_hi=0
extent[i]: block=132-134 len=3 start=1257 start_hi=0
extent[i]: block=135-177 len=43 start=2154 start_hi=0
extent[i]: block=178-194 len=17 start=4206 start_hi=0
extent[i]: block=195-247 len=53 start=1148 start_hi=0
extent[i]: block=248-248 len=1 start=1202 start_hi=0
extent[i]: block=249-249 len=1 start=1249 start_hi=0
extent[i]: block=250-289 len=40 start=1203 start_hi=0
extent[i]: block=290-361 len=72 start=3161 start_hi=0
extent[i]: block=362-366 len=5 start=5222 start_hi=0
extent[i]: block=367-397 len=31 start=3238 start_hi=0
extent[i]: block=398-511 len=114 start=1351 start_hi=0
Inode: 11   Type: regular    Mode:  0644   Flags: 0x80000   Generation:
3161384699
User:     0   Group:     0   Size: 524288
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 1864
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x458bc897 -- Fri Dec 22 06:59:19 2006
atime: 0x458bc897 -- Fri Dec 22 06:59:19 2006
mtime: 0x458bc897 -- Fri Dec 22 06:59:19 2006
BLOCKS:
(IND):1201, (0-502):645-1147, (76-107):589-620, (116-131):629-644,
(132-134):1257-1259, (135-177):2154-2196, (178-194):4206-4222,
(195-247):1148-1200, (248):1202, (249):1249, (250-289):1203-1242,
(290-361):3161-3232, (362-366):5222-5226, (367-397):3238-3268,
(398-511):1351-1464
TOTAL: 932


Above we can see that block numbers from 68 to 502 are each covered by
more than one extent (besides couple of holes, which also might be part
of the same problem).

Note: A "u" in extent[u] donates that this extent is
uninitialized, and thus was created as part of preallocation and noone
has written to it. An "i" signifies that the extent is initialized.

I am trying to solve this issue currently. Any suggestions are more than
welcome.. :)

Regards,
Amit Arora

> 
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
-
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