linux-ext4 - Re: delayed extent tree test cases

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: <CAGBYx2binmZZnOsEva0e_vxWhzFSv6gVnU35yRVyWTSXGXKp=A@mail.gmail.com>
Date:	Fri, 9 Mar 2012 17:19:43 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Lukas Czerner <lczerner@...hat.com>,
	"Ted Ts'o" <tytso@....edu>, Mingming Cao <cmm@...ux.vnet.ibm.com>
Subject: Re: delayed extent tree test cases

> Alrighty, I'll give it a run through xfstests tonight, and then maybe I can
> show you what I've got so far.  My first few patches are pretty much just
> renaming things from delayed_extent to status_extent, sense it's doing a lot
> more than delayed extents now.  I figured those patches we could just merge
> together sense I dont think your set has been merged yet.
Agree!  This can reduce Ted's work.

>
> The next step that I am working on now is getting it to track allocated
> extents.  So any pointers for doing that would be helpful :)  It looks like
> the current code is optimized for merging extents as much as possible, and
> that makes sense for delayed extents, but for allocated extents, we need to
Yep, it is optimized much for delayed extents.
> get it to mirror the existing extents.  That way we will know what extents
> there are to lock before we start doing things with the current extent tree.
>
> When I think about all the ins and outs of trying to keep the trees in sync,
Actually, delayed extents is also synced.  This can be easily achieved
by protecting operations on extent tree by i_data_sem.

> I realize it may get complex, but I dont think we would want to deal with
> the odd things that might come out of allowing tasks to lock a partial
> extent either.  Suggestions for simplifications are certainly welcome though
> :)
I am a little confused by partial extent here.  I am guessing you
meant extent rb-tree in memory is the mirror of extent tree in inode
which is stored on disk.  Am I right?

In my head, the extent tree used by extent lock traces logical
extents, for example, a process locks a range of a file and it does
not care the physical blocks.    So we just need to record logical
extent without physical blocks infos.  Then locking on an extent may
trigger splitting on an extent while unlocking may trigger merging on
extents.  Am I right?

Yongqiang.


>
> Thx!
> Allison Henderson
>



-- 
Best Wishes
Yongqiang Yang
--
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